Re: Coping with 'C' vs 'newC' function language names - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: Coping with 'C' vs 'newC' function language names
Date
Msg-id 3A15B7AE.7D42D4AA@alumni.caltech.edu
Whole thread Raw
In response to Re: Coping with 'C' vs 'newC' function language names  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Coping with 'C' vs 'newC' function language names  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> 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


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: Fundamental change of locking behavior in 7.1
Next
From: Hannu Krosing
Date:
Subject: Re: Coping with 'C' vs 'newC' function language names