Re: Coping with 'C' vs 'newC' function language names - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Coping with 'C' vs 'newC' function language names
Date
Msg-id 200011171734.MAA26108@candle.pha.pa.us
Whole thread Raw
In response to Re: Coping with 'C' vs 'newC' function language names  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Coping with 'C' vs 'newC' function language names  (Peter Eisentraut <peter_e@gmx.net>)
Re: Coping with 'C' vs 'newC' function language names  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> I didn't want to do this during development, but now that there are no
> more old-style internal functions left, I suppose you could make a good
> argument that this is worth doing for old-style dynamically loaded
> functions.  Will put it on the to-do list.
> 
> Are people satisfied with the notion of requiring an info function
> to go with each dynamically loaded new-style function?  If so, I'll
> start working on that too.

I think we need to balance portability with inconvenence for new users.

I think mixing new/old function types in the same object file is pretty
rare, and the confusion for programmers of having to label every
function seems much more error-prone.

I would support a single symbol to mark the entire object file.  In
fact, I would require old-style functions to add a symbol, and have
new-style functions left alone.

There are not that many functions out there, are there?  People are
having to recompile their C files anyway for the upgrade, don't they?


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Next
From: Larry Rosenman
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)