Re: Adding Node support in outfuncs.c and readfuncs.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Adding Node support in outfuncs.c and readfuncs.c
Date
Msg-id 24907.1321489790@sss.pgh.pa.us
Whole thread Raw
In response to Re: Adding Node support in outfuncs.c and readfuncs.c  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Adding Node support in outfuncs.c and readfuncs.c
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> This is a massive amount of code that very few people in our community
>> will use, and very few be able to maintain it, too.

It's not that "massive", at least not as it stands, although I agree it
looks distressingly write-only.

>> If you want to make
>> a lasting contribution on this area, write a program that generates the
>> node handling functionality automatically as part of the build process.

> Can emacs --batch be used there?  If not, apart from C and perl, what
> can I use?

You can *not* assume that emacs is available in any random build
environment; and not C either, because it might be a cross-compile.
It'd have to be Perl.

FWIW, even though I use emacs exclusively, I have little or no interest
in this approach myself.  I don't think the node functions are as
boilerplate as you think --- for one thing, how will you deal with
typedef'd field types?  (Assuming any unknown type name is a node type
is not right.)  And even ignoring that, there are always exceptions to
any general rule.

If Peter is seriously suggesting that construction of the backend/nodes
files could be automated entirely, I think he's nuts.  The amount of
work to construct a bulletproof tool (if it's possible at all) would
greatly outweigh the benefit.  What you've got here could be useful
to people who use emacs and understand they've got to hand-check the
results.  I'm not sure how much further it'd be useful to go.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ISN was: Core Extensions relocation
Next
From: Robert Haas
Date:
Subject: Re: Minor optimisation of XLogInsert()