Re: Last call for comments: fmgr rewrite [LONG] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Last call for comments: fmgr rewrite [LONG]
Date
Msg-id 12459.958968500@sss.pgh.pa.us
Whole thread Raw
In response to Re: Last call for comments: fmgr rewrite [LONG]  (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>)
List pgsql-hackers
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
>> Possibly, or else I'm missing yours.  What would a stub code generator
>> do for us that the proposed GETARG and RETURN macros won't do?

> Only that it might be slightly cleaner code, but you're probably right.
> I just have experience doing this sort of thing and know that manually
> grabbing each argument can be painful with hundreds of functions.

The conversion is going to be a major pain in the rear, no doubt about
that :-(.  I suspect it may take us more than one release cycle to get
rid of all the old-style functions in the distribution, and we perhaps
will never be able to drop support for old-style dynamically loaded
functions.

OTOH, I also have experience with code preprocessors and they're no fun
either in an open-source environment.  You gotta port the preprocessor
to everywhere you intend to run, make it robust against a variety of
coding styles, etc etc.  Don't really want to go there.

On the third hand, you've got the germ of an idea: maybe a really
quick-and-dirty script would be worth writing to do some of the basic
conversion editing.  It wouldn't have to be bulletproof because we
would go over the results by hand anyway, but it could help...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Chris Bitmead
Date:
Subject: Re: Last call for comments: fmgr rewrite [LONG]
Next
From: "Michael A. Olson"
Date:
Subject: Re: Berkeley DB...