Closed cofin closed 1 month ago
hey @cofin, probably not unless the PR is extremely minimal. i don't think there would be much benefit to it. going to close this issue for now but happy to discuss
@tobymao maybe I could ask for your opinion then.
The LGPL license that psycopg
has is problematic for my use case (and many other organization have a similar stance). What was the reason for using psycopg
over asyncpg
? Are there additional features (other than sync support) that psycopg
offers?
Just to further clarify my use case. All of the databases I would connect to are Google CloudSQL or AlloyDB instances. There's a convenient asyncpg
integration for the auth proxy, but there is no such library for psycopg
.
@cofin i change my mind. due to it being lgpl, i'll accept a PR that replaces psycopg with it. will you make a PR? i'm currently quite constrained so may not be able to do it
@tobymao, Thanks for reconsidering. I don't mind creating the PR, and I've actually made a bit of progress on it already. Did you want me to remove the psycopg implementation or allow for either to be used?
probably remove it. is it a pretty easy switch?
probably remove it. is it a pretty easy switch?
Yes, for the most part.
The main changes are around prepared statements and the way the listen/notify mechanism works. I'll submit the PR with them both added, you can weigh in once more. At that point, I can remove the psyocpg adapter before we merge.
It's nice to see a Postgres backend added. I'm just starting to experiment with it, and so far, it's great.
I'm curious do you have plans to offer an an
asyncpg
based Queue in addition the currentpsycopg
implementation? If not, would you be willing to accept a PR adding support?