Postgres and other database interfaces

[Joe]

On Sunday, 25 February 2018 at 16:31:45 UTC, Denis F wrote:
> 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.

Nobody said or implied anything about dropping Postgres 
functionality. If you can, please take a look at the contents of 
the Psycopg docs (http://initd.org/psycopg/docs/), the most 
popular Python Postgres adapter: after the entries for the 
connection and cursor classes, you'll see pyscopg2.extensions, 
pyscopg2.extras, psycopg2.pool and more. It even includes support 
for the recently added logical replication feature.

The "sacrifice" benefits the library implementors because it 
expands their potential market.  Even though you decry the 
differences between RDBMS, when it comes to the basics, I would 
argue that 80% of the code written by a SQL DB developer is very 
similar: connect to the DBMS (or to a file for sqlite), issue a 
query, retrieve results, update some rows.  If they're writing in 
C, D, Python, Ruby or whatever, most of their time is spent 
writing or tweaking SQL statements.  We're not talking about 
MongoDB, Cassandra, OODBMS or other creatures that *do* have 
significant differences (it's telling that several have 
implemented SQL layers on top).

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

Please take a look at the list of RDBMSs supported by SQLAlchemy 
(http://docs.sqlalchemy.org/en/latest/core/engines.html#supported-databases).  I'm *not* in favor of ORMs, but do you think that Mike Bayer (the implementor) would have had any incentive to write an ORM if a DB-API hadn't existed about 10 years before (v1 I believe is circa 1996, v2 from 1999, SQLA came out in 2006 and it already supported four DBMSs).  Even if he had had the incentive it definitely would've been much slower and error-prone, because he would have had to not only design and implement an ORM but also have to deal with idiosyncracies of each library, whereas now he can support multiple libraries for each DBMS, e.g., psycopg2 and pg8000 for Postgres, because they both conform to the same API.

You're obviously reluctant of having to rewrite dpq2 just to 
"play along with the other kids".  I can understand that, but who 
knows, maybe your design is 90% of what the others want/have/like 
and you may only have to make some trivial changes here and there.

In any case, as I mentioned earlier, I will delve into dpq2 (and 
vibe-d-postgresql) for my own project.  So I'll keep in touch.

Joe