fix(postgres): use non-prepared statements for metadata queries#4226
Open
fix(postgres): use non-prepared statements for metadata queries#4226
Conversation
abonander
changed the title
Collaborator
Author
|
@v0idpwn do you mind trying this branch and see if it addresses the issue in your PR #4062? This is the approach I had in mind in #4062 (comment) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Does your PR solve an issue?
Avoids the use of prepared statements to fetch type metadata to improve compatibility with third-party databases that don't support named prepared statements.
Additionally, metadata queries are batched as much as possible, to reduce round-trips to the server. This should reduce query preparation overhead as well as overhead in the query macros.
This also batches the queries used to populate
ColumnOrigindata for the macros (it may be a good idea to batch this further with theattnotnullquery used to seed the nullability analysis).closes #4062 (superceded PR)
Is this a breaking change?
Should not be. Any changes in type resolution should be considered a regression.