Thread: [COMMITTERS] pgsql: Add missing support for new node fields
Add missing support for new node fields Commit b6fb534f added two new node fields but neglected to add copy and comparison support for them, Mea culpa, should have checked for that. per buildfarm animals with -DCOPY_PARSE_PLAN_TREES Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/8bc40533d61da972df63c0960965044dc485b147 Modified Files -------------- src/backend/nodes/copyfuncs.c | 2 ++ src/backend/nodes/equalfuncs.c | 2 ++ 2 files changed, 4 insertions(+)
> Add missing support for new node fields > > Commit b6fb534f added two new node fields but neglected to add copy and > comparison support for them, Mea culpa, should have checked for that. I've been annoyed by these stupid functions and forgetting to update them since I run into them while trying to fix an issue in pg_stat_statement some time ago. I've started to develop a perl script to generate most of them from headers. It is not done yet, but it looks that it can work in the end with limited effort. Currently it works for copy & equal. Is there some interest to generate the x00kB of sources rather than edit them everytime, or forgetting it from time to time, or does everyone like it as it is? -- Fabien.
Hi, On 2017-03-21 07:22:57 +0100, Fabien COELHO wrote: > > Add missing support for new node fields > > > > Commit b6fb534f added two new node fields but neglected to add copy and > > comparison support for them, Mea culpa, should have checked for that. > > I've been annoyed by these stupid functions and forgetting to update them > since I run into them while trying to fix an issue in pg_stat_statement some > time ago. > > I've started to develop a perl script to generate most of them from headers. > It is not done yet, but it looks that it can work in the end with limited > effort. Currently it works for copy & equal. It'd have to do out/read as well imo. > Is there some interest to generate the x00kB of sources rather than edit > them everytime, or forgetting it from time to time, or does everyone like it > as it is? From my POV yes. But it's not quite as trivial as just generating it based on fields. Some fields are intentionally skipped, e.g. location, for equalfuncs, but not copy/out/readfuncs. So there needs to be a way to specify such special rules. - Andres
Hello Andres, >> It is not done yet, but it looks that it can work in the end with limited >> effort. Currently it works for copy & equal. > > It'd have to do out/read as well imo. Sure. This part is WIP, though. >> Is there some interest to generate the x00kB of sources rather than edit >> them everytime, or forgetting it from time to time, or does everyone like it >> as it is? > > From my POV yes. But it's not quite as trivial as just generating it > based on fields. Some fields are intentionally skipped, e.g. location, > for equalfuncs, but not copy/out/readfuncs. So there needs to be a way > to specify such special rules. Indeed, I noticed these particularities... For some case it can be automated with limited input. For really special cases (eg a few read/out functions) , the script is told to skip some node types and the special manual version is taken from the file instead of being generated. -- Fabien.