Allow non-preparable queries in postgres_query - #565
Merged
Conversation
After duckdb#552 the `postgres_query()` function is also used to run DDL and DML queries. Though the queries are still being prepared on a remote server before execution (this is necessary to get the resulting columns during binding) - the same "general" code path is used for both `SELECT`s and DML queries. For majority of the queries this does not cause problems, as Postgres (comparing to other DBs) has minimal limitations to queries that cannot be prepared. Though two notable groups that cannot be prepared contain utility queries (like `VACUUM`) and concatenated multi-query strings. This PR adds support for a `prepare=FALSE` named parameter to `postgres_query()` that makes such calls to use the "fast-path", when the input string is run in Postgres at once without preparing it. This non-prepared mode does not allow to specify query parameters and does not return a result set - intended to be used only with utility or DML queries. Testing: existing `postgres_query` test is updated with multi-query strings coverage.
staticlibs
added a commit
to staticlibs/ducklake
that referenced
this pull request
Sep 2, 2026
This PR effectively reverts [the change](duckdb@7f2f82c) to `PostgresMetadataManager` that was added in duckdb#1407. It is understood, that usage of `postgres_execute()` in `PostgresMetadataManager` does not expect (and does not need) the queries to be prepared in Postgres server before execution. To facilitate this usage, the `prepare=FALSE` named parameter is being added to `postgres_execute()` in duckdb/duckdb-postgres#565. Note 1: the PR is filed as a draft, intended to be undrafted after the `prepare=FALSE` PR is merged and after `duckdb-postgres` version is bumped in the `duckdb/duckdb` repo. Note 2: it is expected, that even after the full support of the [RemoteExecute optimizer](duckdb/duckdb#22914) is added (still pending for Postgres), the `prepare=FALSE` still can be useful. As `RemoteExecute` will result into a query like this: ```sql CALL postgres_execute('s', '<DML1>');CALL postgres_execute('s', '<DML2>');... ``` when the following (original logic before duckdb#1407) may be prefferred instead: ```sql CALL postgres_execute('s', '<DML1>;<DML2>;...') ```
Dtenwolde
pushed a commit
to Dtenwolde/duckdb
that referenced
this pull request
Sep 3, 2026
This PR updates the Postgres extension to bring in the duckdb/duckdb-postgres#565 change to unblock the DuckLake PR duckdb/ducklake#1430.
Dtenwolde
pushed a commit
to Dtenwolde/duckdb
that referenced
this pull request
Sep 3, 2026
This PR updates the Postgres extension to bring in the duckdb/duckdb-postgres#565 change to unblock the DuckLake PR duckdb/ducklake#1430.
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.
After #552 the
postgres_query()function is also used to run DDL and DML queries. Though the queries are still being prepared on a remote server before execution (this is necessary to get the resulting columns during binding) - the same "general" code path is used for bothSELECTs and DML queries.For majority of the queries this does not cause problems, as Postgres (comparing to other DBs) has minimal limitations to queries that cannot be prepared. Though two notable groups that cannot be prepared contain utility queries (like
VACUUM) and concatenated multi-query strings.This PR adds support for a
prepare=FALSEnamed parameter topostgres_query()that makes such calls to use the "fast-path", when the input string is run in Postgres at once without preparing it.This non-prepared mode does not allow to specify query parameters and does not return a result set - intended to be used only with utility or DML queries.
Testing: existing
postgres_querytest is updated with multi-query strings coverage.