On Mon, Oct 03, 2011 at 10:41:48AM -0400, Tom Lane wrote: > Andrew Dunstan <and...@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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
