Re: Would it be possible to backpatch Close support in libpq (28b5726) to PG16?
On 8/15/23 15:39, Alvaro Herrera wrote: On 2023-Aug-16, Michael Paquier wrote: Personally I think backpatching 28b5726 has a really low risk of breaking anything. I agree about the low-risk argument, though. This is just new code. Here's a way to think about it. If 16.1 was already out, would we add libpq support for Close to 16.2? Seems pretty clearly a "no" to me. -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Re: Would it be possible to backpatch Close support in libpq (28b5726) to PG16?
On 2023-Aug-16, Michael Paquier wrote: > > Personally I think backpatching 28b5726 has a really low risk of > > breaking anything. > > I agree about the low-risk argument, though. This is just new code. Here's a way to think about it. If 16.1 was already out, would we add libpq support for Close to 16.2? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
Re: Would it be possible to backpatch Close support in libpq (28b5726) to PG16?
On Wed, Aug 16, 2023 at 12:14:21AM +0200, Jelte Fennema wrote: > 28b5726 allows sending Close messages from libpq, as opposed to > sending DEALLOCATE queries to deallocate prepared statements. Without > support for Close messages, libpq based clients won't be able to > deallocate prepared statements on PgBouncer, because PgBouncer does > not parse SQL queries and only looks at protocol level messages (i.e. > Close messages for deallocation). The RMT has the final word on anything related to the release, but we are discussing about adding something new to a branch that has gone through two beta cycles with a GA targetted around the end of September ~ beginning of October based on the trends of the recent years. That's out of the picture, IMO. This comes once every year. > Personally I think backpatching 28b5726 has a really low risk of > breaking anything. I agree about the low-risk argument, though. This is just new code. -- Michael signature.asc Description: PGP signature
Would it be possible to backpatch Close support in libpq (28b5726) to PG16?
Hi, I know that this will probably get a staunch "No" as an answer, but... I'm still going to ask: Would it be possible to backport 28b5726 to the PG16 branch? Even though it's clearly a new feature? I'm working on named prepared statement support in PgBouncer: https://github.com/pgbouncer/pgbouncer/pull/845 That PR is pretty close to mergable (IMO) and my intention is to release a PgBouncer version with prepared statement support within a few months. 28b5726 allows sending Close messages from libpq, as opposed to sending DEALLOCATE queries to deallocate prepared statements. Without support for Close messages, libpq based clients won't be able to deallocate prepared statements on PgBouncer, because PgBouncer does not parse SQL queries and only looks at protocol level messages (i.e. Close messages for deallocation). Personally I think backpatching 28b5726 has a really low risk of breaking anything. And since PgBouncer is used a lot in the Postgres ecosystem, especially with libpq based clients, IMO it might be worth deviating from the rule of not backporting features after a STABLE branch has been cut. Otherwise all libpq based clients will have only limited support for prepared statements with PgBouncer until PG17 is released. Jelte
