Re: Portal->commandTag as an enum
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>,
Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-02-11T20:54:11Z
Lists: 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
Commits
-
Update comment
- b234b567ed74 13.0 landed
-
Represent command completion tags as structs
- 2f9661311b83 13.0 landed