Re: specifying repeatable read in PGOPTIONS

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: specifying repeatable read in PGOPTIONS
Date: 2014-02-07 10:06:12
Message-ID: 20140207100612.GU28649@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

On 2014-02-04 12:02:45 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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 Content-Type Size
0001-Allow-escaping-of-option-values-for-options-passed-a.patch text/x-patch 3.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-02-07 10:18:33 Re: Recovery inconsistencies, standby much larger than primary
Previous Message Christian Kruse 2014-02-07 09:34:39 Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication