Postgres and other database interfaces

Joe jma at freedomcircle.com
Sun Feb 25 15:34:00 UTC 2018


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. 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.

> 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 (in 
the case of D an alias may be all that is needed to resolve such 
an impasse).

Joe


More information about the Digitalmars-d mailing list