On Tue, Oct 20, 2009 at 10:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
How about warning for release before making the big switch? The text cast change, while ultimately good, maybe could have been stretched out for a release or two...it was painful. I do though absolutely think that it was good in the end to not support a compatibility option in core. Didn't we have a long discussion on big compatibility changes with the consensus that we were to going give a transition release before we dropped a backwards compatibility bomb? I can't help feeling that we are about to jump off into the abyss... merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
