Previously prepared statements and the extended protocol were broken. We need to support this feature because pretty much every client library uses it. The reason that prepared statements did not work is that for prepared statements to work, a Postgres plan needs to be fully copyable using Postgres functionality. We were previously storing the DuckDB plan in the Postgres plan, but since Postgres did not know how to copy the DuckDB plan it would fail.
To work around that problem we now store the full Postgres Query structure inside the DuckDB CustomScan node. Then during execution we use this Query structure to re-plan the query during execution. This works but it has the big downside that we're now planning the query twice in DuckDB, once during planning to get the the column types of the result and once during execution. For now that seems acceptable, so we can at least support prepared statements and the extended protocol. In the future we might want to do something smarter though, like serializing and deserializing the DuckDB plan that is created at planning time.
Note: This does not support all our supported types as arguments to a prepared statement yet. After merging I'll open separate issue to track adding the rest of these types.
Previously prepared statements and the extended protocol were broken. We need to support this feature because pretty much every client library uses it. The reason that prepared statements did not work is that for prepared statements to work, a Postgres plan needs to be fully copyable using Postgres functionality. We were previously storing the DuckDB plan in the Postgres plan, but since Postgres did not know how to copy the DuckDB plan it would fail.
To work around that problem we now store the full Postgres
Querystructure inside the DuckDB CustomScan node. Then during execution we use thisQuerystructure to re-plan the query during execution. This works but it has the big downside that we're now planning the query twice in DuckDB, once during planning to get the the column types of the result and once during execution. For now that seems acceptable, so we can at least support prepared statements and the extended protocol. In the future we might want to do something smarter though, like serializing and deserializing the DuckDB plan that is created at planning time.Note: This does not support all our supported types as arguments to a prepared statement yet. After merging I'll open separate issue to track adding the rest of these types.
Fixes #118