Re: Portal->commandTag as an enum
От | Mark Dilger |
---|---|
Тема | Re: Portal->commandTag as an enum |
Дата | |
Msg-id | 2304E9A7-0454-451B-9A83-9798E761EA25@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Portal->commandTag as an enum (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Portal->commandTag as an enum
|
Список | pgsql-hackers |
> On Feb 11, 2020, at 12:50 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > On 2020-Feb-11, Mark Dilger wrote: > >> I thought about generating the files rather than merely checking them. >> I could see arguments both ways. I wasn’t sure whether there would be >> broad support for having yet another perl script generating source >> files, nor for the maintenance burden of having to do that on all >> platforms. Having a perl script that merely sanity checks the source >> files has the advantage that there is no requirement for it to >> function on all platforms. There’s not even a requirement for it to >> be committed to the tree, since you could also argue that the >> maintenance burden of the script outweighs the burden of getting the >> source files right by hand. > > No thanks. I’m not sure which option you are voting for: (Option #1) Have the perl script generate the .c and .h file from a .dat file (Option #2) Have the perl script validate but not generate the .c and .h files (Option #3) Have no perl script, with all burden on the programmer to get the .c and .h files right by hand. I think you’re voting against #3, and I’m guessing you’re voting for #1, but I’m not certain. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: