Support unnamed prepared statements

[sjuls]

This PR fixes a minor issue we've encountered when using the standard golang postgres driver. It uses unnamed prepared statements to do one-off parameterized queries via QueryContext - these are often failing with could not query: pq: unnamed prepared statement does not exist errors.

The current logic effectively results in unnamed prepared statements being 'disabled' - they do not get cached and pre-prepared on bind and therefore fail if PARSE and BIND are distributed across two different servers.

PR includes;

• Added golang test suite to reproduce the issue
• Implemented fix to allow caching of unnamed prepared statements

[sjuls]

Hm, this breaks the ruby prepared statement tests - missed that locally 🤦

[sjuls]

Hi @levkk,

What's the procedure to update the pgcat-ci container image? I would like to install golang to run the golang test-suite in this PR to validate prepared statements work with the golang pg driver 🙏

Should I make a separate PR for updating the docker files?

[levkk]

Hi @levkk,

What's the procedure to update the pgcat-ci container image? I would like to install golang to run the golang test-suite in this PR to validate prepared statements work with the golang pg driver 🙏

Should I make a separate PR for updating the docker files?

Hello. I think you can just install golang in CI, we use Circle. If needed, you could also make a separate PR.

[sjuls]

Yeah, just seems like circle pulls pgcat-ci:latest, doesn't build the Dockerfile.ci on the branch. I'll make a separate PR to get the pgcat-ci:latest loaded with golang.

Thanks!

[sjuls]

Thank you for the merge of golang in pgcat-ci, @levkk - Looks like the tests are passing now.

Let me know what you think of this PR, and whether there is anything I'm overlooking. I've deployed a build of this branch on our internal test setup and our queries are now going through.

[levkk]

Looks great, thank you!

[zainkabani]

Want to call out the pgbouncer currently doesn't support caching unnamed statements like this so thank you for adding that!

[drdrsh]

I think we will want to put this feature behind a config. Unnamed prepared statements are used by many clients to send regular (unprepared) queries to the database. They are typically sent in one burst of P->B->D->E->S packets. Treating this use case as named prepared statements would very quickly eat up the cache storage because we now treat any extended protocol query as a named prepared query.

Also, it will introduce unexpected new behavior, as we will now be using caching query plans for unnamed prepared statements and that may have negative performance consequences (unlikely but possible due to suboptimal cached plans)