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...)
Given that the global default will be throw-error, I don't feel a need
to kluge up pg_dump to insert #option in old function definitions;
that's ugly and there are too many cases it would not cover. But that
could be added to this proposal if folks feel strongly enough.
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
