Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
От | Robert Haas |
---|---|
Тема | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Дата | |
Msg-id | CA+TgmoZAUmXC7zaFZUanFYhTg3heHsQapCxdkUSA3mSDXgoy4A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs (Jelte Fennema-Nio <postgres@jeltef.nl>) |
Ответы |
Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
|
Список | pgsql-hackers |
On Tue, Aug 20, 2024 at 11:53 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote: > On Tue, 20 Aug 2024 at 17:46, Robert Haas <robertmhaas@gmail.com> wrote: > > I personally like this less than both (a) adding a new function and > > (b) redefining the existing function as Jelte proposes. It just seems > > too clever to me. > > Agreed, I'm not really seeing a benefit of returning 4 instead of > 30004. Both are new numbers that are higher than 3, so on existing > code they would have the same impact. But any new code would be more > readable when using version >= 30004 imho. Yes. And the major * 10000 + minor convention is used in other places already, for PG versions, so it might already be familiar to some people. I think if we're going to redefine an existing function, we might as well just redefine it as you propose -- or perhaps even redefine it to return major * 10000 + minor always, instead of having the strange exception for 3.0. I think I'm still on the side of not redefining it, but if we're going to redefine it, I think we should do what seems most elegant/logical and just accept that some code may break. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: