On 2014-02-09 12:38:18 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sun, Feb 9, 2014 at 12:10 PM, Andres Freund <andres@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
