Re: proposal \gcsv

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal \gcsv
Дата
Msg-id 21171.1585758591@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal \gcsv  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: proposal \gcsv
Re: proposal \gcsv
Список pgsql-hackers
Pavel Stehule <pavel.stehule@gmail.com> writes:
> It can work, but it is not user friendly - my proposal was motivated by
> using some quick csv exports to gplot's pipe.

I kind of liked the stack idea, myself.  It's simpler than what I was
suggesting and it covers probably 90% of the use-case.

However, if we prefer something closer to Plan A ... I took a look at
the psql lexer, and the only difference between OT_FILEPIPE and OT_NORMAL
parsing is if the argument starts with '|'.  So we could make it work
I think.  I'd modify my first proposal so far as to make it

    \g ( pset-option pset-value ... ) filename-or-pipe

That is, require spaces around the parens, and require a value for each
pset-option (no fair using the shortcuts like "\pset expanded").  Then
it's easy to separate the option names and values from the paren markers.
The \g parser would consume its first argument in OT_FILEPIPE mode, and
then if it sees '(' it would consume arguments in OT_NORMAL mode until
it's found the ')'.

This way also narrows the backwards-compatibility problem from "fails if
your filename starts with '('" to "fails if your filename is exactly '('",
which seems acceptably improbable to me.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: wraparound dangers in snapshot too old
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join