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.

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

- Thomas