Re: proposal \gcsv - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal \gcsv
Date
Msg-id 21171.1585758591@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal \gcsv  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal \gcsv  (Vik Fearing <vik@postgresfriends.org>)
Re: proposal \gcsv  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: wraparound dangers in snapshot too old
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join