Re: specifying repeatable read in PGOPTIONS - Mailing list pgsql-hackers

From Andres Freund
Subject Re: specifying repeatable read in PGOPTIONS
Date
Msg-id 20140207100612.GU28649@alap3.anarazel.de
Whole thread Raw
In response to Re: specifying repeatable read in PGOPTIONS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: specifying repeatable read in PGOPTIONS  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi Tom,

On 2014-02-04 12:02:45 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-02-04 11:36:22 -0500, Tom Lane wrote:
> >> -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.
>
> application_name --- weren't we just reading about people passing entire
> command lines there?  (They must be using some other way of setting it
> currently, but PGOPTIONS doesn't seem like an implausible source.)

You can't easily use PGOPTIONS to set application_name in many cases
anyway, libpq's support for it gets in the way since it takes effect
later. And I think libpq is much more likely way to set it. Also you can
simply circumvent the problem by using a different naming convention,
that's not problem with repeatable read.

So I still think we should add read_committed, repeatable_read as aliases.

> >> 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 \?
>
> The same thought had occurred to me.  Since it'll typically already be
> inside some levels of quoting, any quoted-string convention seems like
> it'd be a pain to use.  But a straight backslash-escapes-the-next-char
> thing wouldn't be too awful, I think.

Ok, here's a patch implementing that. There's a slight backward concern
in that a \ would earlier have been passed through unmodified, but now
would be taken as a escape. I think that's not too much of a problem
though.
I thought about simply outputting the escape unless it's been used as an
escape before a speace, but that seems like a bad idea, barring future
uses to me.

Greetings,

Andres Freund

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

Attachment

pgsql-hackers by date:

Previous
From: Christian Kruse
Date:
Subject: Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication
Next
From: Andres Freund
Date:
Subject: Re: Recovery inconsistencies, standby much larger than primary