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.
