Re: Controlling changes in plpgsql variable resolution - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Controlling changes in plpgsql variable resolution
Date
Msg-id b42b73150910211328p6ef3f36cwedf974b321f4d754@mail.gmail.com
Whole thread Raw
In response to Re: Controlling changes in plpgsql variable resolution  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Controlling changes in plpgsql variable resolution
List pgsql-hackers
On Wed, Oct 21, 2009 at 3:09 PM, Josh Berkus <josh@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
andthe 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: alpha2 bundled -- please verify
Next
From: Simon Riggs
Date:
Subject: Re: Hot standby, prepared xacts, locks