Re: Controlling changes in plpgsql variable resolution

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane 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.

> 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?

That's only sane if you are 100% certain that there could not be a
security issue arising from the change of behavior. Otherwise someone
could for instance subvert a security-definer function by running it
under the setting it wasn't written for. Personally I am not 100%
certain of that.

> 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

Yeah, that's another reason to not allow it to be changed too easily.

> Also, I am not really keen on the "keep it for a few releases"

Well, I'm not necessarily saying we would ever change it. Maybe the
default could always stay at "error".

> ... maybe just error/no error
> and using Oracle semantics is the way to go, with 'error' as the
> default.

I'd personally be entirely happy with that, but people with large
plpgsql code bases will not be. They're going to want a
backward-compatible setting so that this doesn't become a show stopper
for migration to 8.5. Any time you can allow someone to deal with a
migration issue later instead of right away, it becomes easier for them
to migrate.

regards, tom lane