On 2014-08-28 10:20:08 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-08-28 10:12:19 -0400, Tom Lane wrote: > >> Hm. Yeah, I guess there is some use in holding onto the values that were > >> actually used to initialize the current session, or at least there would > >> be if we exposed the cert contents in any fashion. > > > Won't that allow the option to be specified at connection start by mere > > mortal users? That sounds odd to me. > > Well, no, because SSL would be established (or not) before we ever process > the contents of the connection request packet. You might be able to > change the value that SHOW reports, but not the value actually governing > your session.
Sure. There's probably nothing happening with ssl 'that late' right now. But and it seems like a invitation for trouble later to me. Even if it's just that other code copies the logic, thinking it'd also be safe. > Having said that, there's a nearby thread about inventing a "SUBACKEND" > GUC category, and that's likely what we'd really want to use here, just > on the grounds that superusers would know better. What we really want is PGC_SIGHUP | PGC_BACKEND, right? I wonder if it's not better to allow for some cominations of GucContext's by bitmask, instead of adding SUBACKEND and HUPBACKEND and whatever else might make sense. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers