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=,) ...
* 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='|')
regards, tom lane
