Re: proposal \gcsv

út 7. 4. 2020 v 16:28 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
> > On Tue, 7 Apr 2020 at 03:30, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>