út 7. 4. 2020 v 16:28 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Isaac Morland <isaac.morland@gmail.com> writes: > On Tue, 7 Apr 2020 at 03:30, Pavel Stehule <pavel.stehule@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='|')
