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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
