Tom Lane wrote: > Andrew Dunstan <and...@dunslane.net> writes: > > Tom Lane wrote: > >> (a) Nobody but me is afraid of the consequences of treating this as > >> a GUC. (I still think you're all wrong, but so be it.) > > > I can't say I'm happy about it. For one thing, the granularity seems all > > wrong. I'd rather be able to keep backwards compatibility on a function > > by function basis. Or would the value of the GUC at the time the > > function was created stick? > > Again, I can't see making a GUC that works fundamentally differently > from the rest of them. > > Given this round of feedback, I make the following proposal: > > 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. -- 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
