Re: automatically generating node support functions
От | Andres Freund |
---|---|
Тема | Re: automatically generating node support functions |
Дата | |
Msg-id | 20220711182915.jd2ibajdcbncqdqd@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: automatically generating node support functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: automatically generating node support functions
|
Список | pgsql-hackers |
Hi, On 2022-07-11 13:57:38 -0400, Tom Lane wrote: > More generally, I'm having second thoughts about the wisdom of > auto-generating the NodeTag enum at all. With the current setup, > I am absolutely petrified about the risk of silent ABI breakage > thanks to the enum order changing. In particular, if the meson > build fails to use the same input-file order as the makefile build, > then we will get different enum orders from the two builds, causing > an ABI discrepancy that nobody would notice until we had catastrophic > extension-compatibility issues in the field. Ugh, yes. And it already exists due to Solution.pm, although that's perhaps less likely to be encountered "in the wild". Additionally, I think we've had to add tags to the enum in minor releases before and I'm afraid this now would end up looking even more awkward? > Of course, sorting the tags by name is a simple way to fix that. > But I'm not sure I want to buy into being forced to do it like that, > because of the switch-density question. > > So at this point I'm rather attracted to the idea of reverting to > a manually-maintained NodeTag enum. +0.5 - there might be a better solution to this, but I'm not immediately seeing it. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: