On 2014-02-09 12:38:18 -0500, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Sun, Feb 9, 2014 at 12:10 PM, Andres Freund <and...@2ndquadrant.com> > > wrote: > >> Why? We do have other options with aliases for option values and all > >> other enum option has taken care not to need spaces. > > > I think that's probably mostly a happy coincidence; I'm not committed > > to a policy of ensuring that all GUCs can be set to whatever value you > > want without using the space character. Besides, what's so special > > about enum GUCs? There can certainly be spaces in string-valued GUCs, > > and you're not going to be able to get around the problem there with > > one-off kludges. > > Pathname GUCs can have spaces in them (that's even pretty common, on > certain platforms). Other GUCs contain SQL identifiers, which can > legally have spaces in them too.
But pretty much all of those GUCs are either PGC_SIGHUP or PGC_POSTMASTER and thus cannot be set via PGOPTIONS anyway. The two exceptions are application_name (which can in many cases not set because libpq overrides it with a SET) and search_path. Anybody setting the latter to schemas containing spaces deserves having to escape values. > So really this is a mechanism > deficiency, not something we should work around by instituting a policy > against spaces in GUC values. Please note, I am absolutely *not* against such a mechanism, that's why I submitted a patch implementing one. But unneccearily requiring escaping still annoys me. We imo should add the escaping mechanism to master and backpatch the aliases (read_committed, repeatable_read). There's already not enough benchmarking during beta/rc, we shouldn't make it unneccesarily hard. And there's sufficient reason to benchmark the difference between isolation modes, with mvcc catalog snapshots and such. 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