On Mon, Oct 03, 2011 at 10:41:48AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > On 10/03/2011 10:17 AM, Tom Lane wrote:
> >> Right. Getting rid of custom_variable_classes should actually
> >> make those use-cases easier, since it will eliminate a required
> >> setup step.
>
> > So are we going to sanction using this as a poor man's session
> > variable mechanism?
>
> People already are doing that, sanctioned or not.
>
> > If so maybe we should at least warn that anything set will be
> > accessible by all roles, so security definer functions for example
> > should be wary of trusting such values.
>
> Since it's not documented anywhere, I'm not sure where we'd put such
> a warning. I think anyone bright enough to think of such a hack
> should be able to see the potential downsides, anyway.
Perhaps it's best to document this usage and include the warning for
those less "bright," as you term them. I'd be less tempted to call
them "not bright" and more tempted to think they might assume
PostgreSQL already takes care of cleaning this up, but whatever.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate