Handle the special case of SELECT set_config(...)#1072
Merged
Conversation
This intercepts queries that are in the simplest form of `set_config`, where it is a select statement containing exactly one call to that function, and all arguments are literals. Any queries like this could have easily been written using `SET` instead, but this is a form that is emitted by pg_dump, which results in sessions being left in a bad state if we don't handle it explicitly. So we have to handle it. I took great care to avoid any allocations when we're checking if the select statement is in a form that we can handle, which was slightly more painful than I'd like since we need to check for both qualified an unqualified function names. Eventually we need to handle this more broadly. `set_config` can appear anywhere in expression context (with undefined execution order, dear god), and can take any expression as an argument including cross-shard queries. When we have a cheaper and more walkable AST, we should at least warn when we encounter this function in any cases where we don't handle. We can't *just* treat it exactly as `SET`, since the function does return a value and so the client may be expecting rows. I've left the implementation of this somewhat extensible so that we can at least handle selections with multiple calls to `set_config` down the road. Realistically, long term, we need to go through the whole AST and replace any calls to this with their value, while figuring out which config settings to apply when... somehow. If we encounter a form that we can't parse (non-literals) Ultimately the very existence of this function is something of an abomination, and I suspect we'll be avoiding dealing with more complex forms for as long as we possibly can. Fixes #1055
levkk
reviewed
Jun 12, 2026
| .clone() | ||
| .into_iter() | ||
| .flatten() | ||
| .map(|_| Field::text("")) |
Collaborator
There was a problem hiding this comment.
I think the columns need to have names?
Contributor
Author
There was a problem hiding this comment.
Columns do, result fields don't. I can double check, but I'm fairly certain this is the behavior of vanilla pg for selections that aren't columns and don't have aliases
Contributor
Author
There was a problem hiding this comment.
Double checked vanillas behavior, it does set it to the function name. I thought for sure that was something psql did on the client side. Since it's the end of the week, I'm just hard coding it for now. I'll definitely remember to fix it on Monday
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
This comment has been minimized.
This comment has been minimized.
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
2 participants
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.
This intercepts queries that are in the simplest form of
set_config, where it is a select statement containing exactly one call to that function, and all arguments are literals. Any queries like this could have easily been written usingSETinstead, but this is a form that is emitted by pg_dump, which results in sessions being left in a bad state if we don't handle it explicitly. So we have to handle it.I took great care to avoid any allocations when we're checking if the select statement is in a form that we can handle, which was slightly more painful than I'd like since we need to check for both qualified an unqualified function names.
Eventually we need to handle this more broadly.
set_configcan appear anywhere in expression context (with undefined execution order, dear god), and can take any expression as an argument including cross-shard queries. When we have a cheaper and more walkable AST, we should at least warn when we encounter this function in any cases where we don't handle.We can't just treat it exactly as
SET, since the function does return a value and so the client may be expecting rows. I've left the implementation of this somewhat extensible so that we can at least handle selections with multiple calls toset_configdown the road. Realistically, long term, we need to go through the whole AST and replace any calls to this with their value, while figuring out which config settings to apply when... somehow.If we encounter a form that we can't parse (non-literals)
Ultimately the very existence of this function is something of an abomination, and I suspect we'll be avoiding dealing with more complex forms for as long as we possibly can.
Fixes #1055