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

> > For that matter, I think past version updates haven't even forced
> > recompiles of user-defined functions, at least not ones that didn't poke
> > into system innards.  We can't get away with requiring a source code
> > change --- people will scream about it.
> 
> imho that is *not* sufficient to keep from Doing The Right Thing. And
> DTRT usually means designing correctly for the future. I would support a
> design that is cleanest for the next release, and put backward
> compatibility a (no so) distant second.

Agreed.

> 
> > The nice thing about the info-marker idea is that we'll be able to
> > extend it later, so that more info about the function is stored right
> > where the function text is, and you don't have such a problem with
> > keeping an SQL script file in sync with the function's real definition.
> 
> I've been wanting to think about the "package" or "module" idea (which
> others have brought up recently). If this kind of hook gets us more
> options to support that (e.g. running a routine when the module is first
> loaded to install new options into "SET key=val") then even better. Lack
> of hooks of this nature lead us to push datatypes down into the core
> when if we had full-up module support we could make more things
> loadable.

One idea we had was to define a SET variable or psql command-line switch
so that LANGUAGE "C" would mean either old or new style.  That way,
pg_dump loads from old versions could set the switch before load without
changing their code, and we could call all functions C.

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