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