Postgres and other database interfaces

[Denis F]

On Sunday, 25 February 2018 at 03:03:05 UTC, Joe wrote:
> On Saturday, 24 February 2018 at 23:04:39 UTC, Denis F wrote:
>> If anyone really want to impliment your idea, at my first 
>> glance at the PEP 249 I had a feeling that this is work for 
>> time less than a 1-2 weeks. It can be a simple wrapper over 
>> dpq2, mysql-native, sqlite3, etc.
>
> I'm not saying that anyone should implement something like PEP 
> 249, particularly *not* as a wrapper over those libraries. My 
> point is that if the implementors of dpq2, mysql-native, etc., 
> could "get together" (at DConf, in forums, by email) and 
> discuss their interfaces, perhaps they could agree on a set of 
> D database interface classes and then each would work towards 
> that common set.

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.

> That's more or less what the Python DB-SIG did. Then every 
> library would benefit because, for one, the common set can be 
> documented just once. Also, if it's a sufficiently reasonable 
> spec, the libraries that don't move towards it should see less 
> adoption because, unless the divergent library has a 
> significantly enhanced interface, developers will shy away from 
> having to learn a different one.
>
> It's the same concept as the SQL (and other) Standards.

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

> There may be variances between implementations but no one has 
> implemented a RETRIEVE or PROJECT statement in lieu of a SELECT 
> statement (and note there *were* relational systems that used 
> the former).

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.