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