From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Jan Wieck <janwieck(at)Yahoo(dot)com>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Coping with 'C' vs 'newC' function language names |
Date: | 2000-11-17 17:34:27 |
Message-ID: | 200011171734.MAA26108@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-11-17 17:35:44 | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Previous Message | Larry Rosenman | 2000-11-17 17:26:22 | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |