Re: Controlling changes in plpgsql variable resolution - Mailing list 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Controlling changes in plpgsql variable resolution
Next
From: "David E. Wheeler"
Date:
Subject: Re: Controlling changes in plpgsql variable resolution