Re: specifying repeatable read in PGOPTIONS

On 2014-02-04 11:36:22 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > PGOPTIONS='-c default_transaction_isolation=serializable' \
> > psql ... -c "SHOW default_transaction_isolation"
> > works well enough, but
> > PGOPTIONS='-c default_transaction_isolation=repeatable read' \
> > psql ... -c "SHOW default_transaction_isolation"
> > doesn't, because of the whitespace. I couldn't come up with any adequate
> > quoting.
>
> > I'd like to propose adding aliases with dashes instead of spaces to the
> > isolation_level_options array? I'd even like to backport it, because it
> > makes benchmarking across versions unneccessarily hard.
>
> -1. This is not a general solution to the problem. There are other
> GUCs for which people might want spaces in the value.

Sure, I didn't say it was. But I don't see any oother values that are
likely being passed via PGOPTIONS that frequently contain spaces. Sure,
you can generate a search_path that does so, but that's just asking for
problems. Most other GUCs that can contain spaces are
PGC_SIGHUP/POSTMASTER.
And having to use quoting just makes it awkward to use from shell. Since
all the other option values try to take not to force using spaces, I see
little reason not to do so here as well.

> > Additionally we might want to think about a bit better quoting support
> > for such options?
>
> Yeah. See pg_split_opts(), which explicitly acknowledges that it'll fall
> down for space-containing options. Not sure what the most appropriate
> quoting convention would be there, but I'm sure we can think of something.

No argument against introducing it. What about simply allowing escaping
of the next character using \?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services