Re: Controlling changes in plpgsql variable resolution - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Controlling changes in plpgsql variable resolution
Date
Msg-id 200910200621.n9K6LBH15250@momjian.us
Whole thread Raw
In response to Re: Controlling changes in plpgsql variable resolution  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: UTF8 with BOM support in psql
Next
From: Magnus Hagander
Date:
Subject: Re: Application name patch - v2