On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <j...@agliodbs.com> wrote: >> Now, when this person attempts to recreate this function on a >> hypothetical version of PostgreSQL that thinks "id" is ambiguous, it >> doesn't work. > > Hence the GUC. Where's the issue?
Behavior-changing GUCs for this kind of thing cause a lot of problems. If you need one GUC setting for your application to work, and the extension you have installed needs the other setting, you're screwed. In the worst case, if a security-definer function is involved, you can create a security hole, for example by convincing the system that id = $1 is intended to mean $1 = $1, or some such. You can of course attach the GUC settings to each individual function, but that doesn't really work either unless you do it for every function in the system. The fundamental problem here is that GUCs are dynamically scoped, while this problem is lexically scoped. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
