Re: specifying repeatable read in PGOPTIONS
От | Andres Freund |
---|---|
Тема | Re: specifying repeatable read in PGOPTIONS |
Дата | |
Msg-id | 20140207100612.GU28649@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: specifying repeatable read in PGOPTIONS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: specifying repeatable read in PGOPTIONS
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: