Re: Controlling changes in plpgsql variable resolution

Andrew Dunstan <andrew(at)dunslane(dot)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