-
Notifications
You must be signed in to change notification settings - Fork 608
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(postgres): use psycopg
rather than psycopg2
#10659
Conversation
8d76d63
to
31312f3
Compare
0345ad5
to
4c83730
Compare
psycopg
rather than psycopg2
for Postgrespsycopg
rather than psycopg2
2fa9f79
to
41c5082
Compare
I was planning to continue this PR when I got the chance. I realized after starting that Rising Wave needed to move too because of the inheritance structure but that one is more difficult to iterate on in local development. |
@judahrand -- what kind of machine are you on? There's a |
If the main use case here is for the postgres backend, then I would suggest we decouple the backends first and then do the upgrade. I can put up a PR for that. As is, even after fixing the top level risingwave integration there are some new, reproducible segfaults. |
df06904
to
5214e45
Compare
…se has not registered it yet
@@ -106,48 +105,6 @@ def _from_url(self, url: ParseResult, **kwargs): | |||
|
|||
return self.connect(**kwargs) | |||
|
|||
def _register_in_memory_table(self, op: ops.InMemoryTable) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a duplicated definition not caught by ruff that I introduced in #10669.
Thanks @judahrand for kicking this off! |
Description of changes
The newer
psycopg
package generally has better performance and is more maintained than the olderpsycopg2
package.Issues closed