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
