Re: Coping with 'C' vs 'newC' function language names

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 22:43:44
Message-ID: 3A15B4A0.508F0D7B@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
>
> > 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?

Can't we insert that magic variable automatically using some
#includ/#define tricks ?

So that people need just to recompile, but the result has the variable
nonetheless ?

-----------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-11-17 22:46:57 Re: Coping with 'C' vs 'newC' function language names
Previous Message Hiroshi Inoue 2000-11-17 22:36:49 RE: Fundamental change of locking behavior in 7.1