Re: Controlling changes in plpgsql variable resolution

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Controlling changes in plpgsql variable resolution
Дата
Msg-id 9440.1255978048@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Controlling changes in plpgsql variable resolution  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Controlling changes in plpgsql variable resolution  ("David E. Wheeler" <david@kineticode.com>)
Re: Controlling changes in plpgsql variable resolution  ("Eric B. Ridge" <ebr@tcdi.com>)
Re: Controlling changes in plpgsql variable resolution  (Bruce Momjian <bruce@momjian.us>)
Re: Controlling changes in plpgsql variable resolution  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> (a) Nobody but me is afraid of the consequences of treating this as
>> a GUC.  (I still think you're all wrong, but so be it.)

> I can't say I'm happy about it. For one thing, the granularity seems all 
> wrong.  I'd rather be able to keep backwards compatibility on a function 
> by function basis. Or would the value of the GUC at the time the 
> function was created stick?

Again, I can't see making a GUC that works fundamentally differently
from the rest of them.

Given this round of feedback, I make the following proposal:

1. Invent a GUC that has the settings backwards-compatible,
oracle-compatible, throw-error (exact spellings TBD).  Factory default,
at least for a few releases, will be throw-error.  Make it SUSET so that
unprivileged users can't break things by twiddling it; but it's still
possible for the DBA to set it per-database or per-user.

2. Also invent a #option syntax that allows the GUC to be overridden
per-function.  (Since the main GUC is SUSET, we can't just use a
per-function SET to override it.  There are other ways we could do this
but none seem less ugly than #option...)

Given that the global default will be throw-error, I don't feel a need
to kluge up pg_dump to insert #option in old function definitions;
that's ugly and there are too many cases it would not cover.  But that
could be added to this proposal if folks feel strongly enough.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution