On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus <j...@agliodbs.com> wrote: > Tom has proposed some kind of odd special "options" syntax to get around > this, but I think that's unnecessary. So far on this thread, I haven't > seen anyone engineer an actual function exploit by using this setting; I > personally can't come up with one off the top of my head which doesn't > require the attacker to be the table owner, the function owner, or the > superuser themselves. Also keep in mind what we're patching here is an > unmaintanable and insecure practice anyway, which is the ambiguous use > of variable names which match column names. > > So, I'm saying: make it a userset.
I couldn't disagree more strongly. .conf entries that adjust how plpgsql funtions operate in a very central way will 'fork' plpgsql develoeprs so that you have one group of people using method 'a' and another using method 'b'. Nobody bothers to fix legacy code and now we have a first class mess. All code intended to run on servers you don't control (like library code) now needs to be decorated with 'set local...' which defeats the whole purpose. IMO, guc settings that control how sql behaves should be avoided at all costs. You should be able to look at a piece of code and explicitly determine what it does. At least with #option, knowing the server version and the function body is enough. if you want to support multiple behaviors but don't like #option, i think the only alternative is to version the plpgsql language somehow and decorate 'create function' with the version. Tom didn't like that idea, but it still beats GUC imo. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
