2011/4/9 Tom Lane <[email protected]>: > Robert Haas <[email protected]> writes: >> On Fri, Apr 8, 2011 at 4:32 PM, Josh Berkus <[email protected]> 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 ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
