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

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: Coping with 'C' vs 'newC' function language names
Дата
Msg-id 3A15B7AE.7D42D4AA@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: Coping with 'C' vs 'newC' function language names  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Coping with 'C' vs 'newC' function language names  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: Fundamental change of locking behavior in 7.1
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Coping with 'C' vs 'newC' function language names