Re: Proposal to allow setting cursor options on Portals
| От | Jelte Fennema-Nio |
|---|---|
| Тема | Re: Proposal to allow setting cursor options on Portals |
| Дата | |
| Msg-id | CAGECzQSfCPXdOpUKfdkPA9iZhGyRjZAad-CXbhApZ2CnjgG2kw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal to allow setting cursor options on Portals (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: Proposal to allow setting cursor options on Portals
|
| Список | pgsql-hackers |
On Tue, 6 Jan 2026 at 17:17, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > Well, I'd hoped that you and Jelte would maybe hash out your > differences in opinion a bit before I jumped back in. You think > extensions are orthogonal -- seemingly negating the primary advantage > cited for regular minor bumps? -- but Jelte is optimizing for > interrelated features. I had a quick discord chat with Dave. And we don't disagree much with each other: We both would like to use a version bump for these kinds of very simple to implement features. For an important part because we hope to do multiple of such small changes in a single PG release, so the protocol can actually move forward at a decent speed. Having a single version is only 1 option, while having N protocol extensions a year gives at least N different configurations (if they're all orthogonal, and at worst N*N). In your first email you (Jacob) wrote this: > I prefer protocol architectures that introduce separate > extensions first, then periodically bundle the critical and > highly-used extensions into a new minor version once they're sure that > _everyone_ should support those things. Dave and I both agree that if we create a protocol extension for every tiny feature and then in 3 years include some of them in a protocol bump, that's just a lot more complexity that every client author will have to deal with in the long run.
В списке pgsql-hackers по дате отправления: