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 |
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 |