Postgres and other database interfaces

[Denis F]

On Sunday, 25 February 2018 at 15:34:00 UTC, Joe wrote:
> On Sunday, 25 February 2018 at 09:07:34 UTC, Denis F wrote:
>> Libraries already are similar automatically because RDBMSes 
>> uses similar principles. But it is impossible to make 
>> libraries absolutely identical due to the presence of 
>> important significant nuances in each engine.
>
> I don't see how making libraries compatible with each other, 
> i.e., complying with some standard, will result in losing 
> functionality.  What I'm talking about is standardizing the 
> names of certain classes and their methods, exceptions, and 
> perhaps some datatypes and the expected order of certain 
> arguments.  For example, instead of having classes named 
> Database (sqlite3), PGConnection (ddb) and Connection (dpq2, 
> mysql-native) there's just one name, and that class is expected 
> to have certain methods.

I guess this is problem too: sqlite isn't connects at all, and 
its struct represents RDBMS itself. But other should represent 
only connections because they manipulate the connection and not 
controls its server, and connection is a potential source of 
connection-related exceptions. This is a subtle but important 
difference too.

> The library implementor can add others. For example, I see 
> mysql-native has a connection pool and that doesn't need to be 
> part of the standard. Also, some methods can be specified as 
> being optional by the standard, e.g., something like callproc, 
> because not all DBMSs support procedures.

This is another confirmation is that there are more differences 
than similarities  between databases. :-)

>
>> Ok, I propose to be consistent and ask for compliance with the 
>> Standard from the RDBMSes. For example, arguments substitution:
>>
>> MySQL uses the '?'
>> PostgreSQL uses $1
>> SQLite accepts both
>> Oracle uses a :name
>>
>> (Really, it is very important to come to an agreement here 
>> because, for sure, the next obvious step is writing an ORM 
>> generator on top of the idea what you are proposing.)
>
> In PEP 249, this was left up to the implementors (see the 
> paramstyle global), but a footnote suggests that some styles 
> are supposed to be preferred over others.
>
>> For example, I would not change unobvious at first sight 
>> system of classes "Result" and inherited from it class 
>> "Answer" for the sake of similarity to other libraries. Simply 
>> because this is the way what Postgres client library works, 
>> and if this classes will be removed some significant 
>> functionality will be lost.
>> I'm sure that in other libraries there is something similar.
>
> I'm not sure I understand your example, but perhaps this is 
> getting too specific and close to the discussions that would 
> need to take place betweeen existing implementors.  There has 
> to be a negotiation process for a standard to be developed.  In 
> my example above, suppose the sqlite3 library developer says "I 
> don't want to have a class named Connection, because my users 
> don't connect to a server".  It will be up to the other 
> developers to convince him or to arrive at some compromise

What are these sacrifices for? I do not like idea that I should 
drop some functionality of Postgres for conpatibility with 
another RDBMSes. Personally, I like specific databases because it 
have nuances of functionality that they provide to me.

And those who wish to "crossbreeding a hedgehog with a snake", at 
first, can try to write a wrapper around existing SQL libraries. 
This is faster and more humane in relation to the developers.