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

> 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 ?

We thought of that.  The problem is some new-style functions do not need
to call any macros.

--  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