Postgres and other database interfaces

[Denis F]

On Sunday, 25 February 2018 at 20:56:16 UTC, Joe wrote:
> 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.

pyscopg2 passes request arguments as strings inside of it! This 
degrades type safety because in D we have types.

Looks like it is uses C format:

cur.execute("SELECT '%s', %s", (123,456,)) -- first arg expected 
as "%s" string
cur.fetchone()
('123', 456)

> 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

No, sure. dpq2 is too lowlevel for this. Users need transactions, 
prepared statements wrappers, etc. But I can't implement it in 
dpq2 because these things is depedend from other more high level 
implementations.

At least, for dpk2, I clearly see that the wrapper is the best 
choice.