Ășt 7. 4. 2020 v 16:28 odesĂ­latel Tom Lane <t...@sss.pgh.pa.us> napsal:

> Isaac Morland <isaac.morl...@gmail.com> writes:
> > On Tue, 7 Apr 2020 at 03:30, Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
> >> your patch supports syntax
> >> (option1=value option2=value)
> >> It looks little bit inconsistent and unusual
>
> > It's the same as a connection string.
>
> Yeah, I didn't exactly invent that out of nowhere.  There are a couple
> of reasons not to add commas to the syntax:
>
> * It would make comma be another character that's hard to put into
> pset values in this context.  And unlike right paren, there's plenty
> of reason to think people would wish to do that, eg \g (fieldsep=,) ...
>

ok, this is valid argument


> * If we use commas then people would figure the spaces are optional
> and would try to write things like \g (expanded,null=NULL) ...
> That moves the goalposts quite a bit in terms of the code having
> to pick apart strings, and it makes things a lot more ambiguous
> than they were before --- notably, now '=' is *also* a character
> that you can't readily write in a pset value.
>
> > Actually, maybe that's the key to
> > allowing parentheses, etc. in option values if needed - allow the same
> > single-quote quoting as in connection strings. Maybe even just call the
> > same code to do the parsing.
>
> I don't think there is a lot of wiggle room to let \g have its own quoting
> rules.  The psqlscanslash lexer has its own ideas about that, which we
> cannot bypass without losing features.  An example is that people would
> expect this to work:
>         \set myfmt '(expanded tuples_only)'
>         \g :myfmt somefile
> So we can't just ask to snarf the input in OT_WHOLE_LINE mode and then
> pick it apart locally in \g.  And having two levels of quoting rules
> would be disastrous for usability.
>
> The lexer does have the ability to report whether an argument was quoted,
> but it doesn't seem to work quite the way we would want here; it actually
> reports whether any part of the argument was quoted.  So if we tried to
> make right paren recognition depend on that, this'd misbehave:
>         \g (fieldsep='|')
>

ok, I have not any objections.

Regards

Pavel


>                         regards, tom lane
>

Reply via email to