Bruce Momjian <br...@momjian.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
