2011/4/9 Tom Lane <t...@sss.pgh.pa.us>: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <j...@agliodbs.com> wrote: >>> 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. > > Yeah. In the plpgsql case, we did make provisions to control the > behavior per-function. In principle we could do the same for SQL > functions, but it'd be rather a PITA I think. (In particular, the "easy > way out" of attaching SET clauses to the functions would be a bad idea > because it would defeat inlining.)
what about a new language like SQLc? - like SQL compatibility. pg_upgrade can move old code into this compatibility language when detect some posible problems. Pavel > > 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
