Re: Controlling changes in plpgsql variable resolution

Bruce Momjian wrote:
> > 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...)
>
> I don't see the logic to making the setting SUSET. The user wrote the
> function; what logic is there to say the resolution rules are not under
> their control?
>
> Also, I think to GUC that throws an error or not is a lot safer than one
> that changes resolution semantics. Changing resolution semantics sounds
> like the autocommit GUC to me. :-O
>
> Also, I am not really keen on the "keep it for a few releases" --- we
> often don't come back to finally change it, so maybe just error/no error
> and using Oracle semantics is the way to go, with 'error' as the
> default. Our change in casting for 8.3 seemed much more major than
> this.

Oh, two more things. First, with the Oracle resolution rules, I think
it is possible to change the behavior of a function by adding or
renaming a column that wasn't referenced in the function because a
new/renamed column might mask a function variable --- that is not nice.

Second, I can see the value of having the GUC be SUSET if changing the
setting could possible break the function or cause insecure behavior,
but I wasn't clear that was possible.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +