Re: psql --batch

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql --batch
Date: 2017-08-28 07:05:29
Message-ID: CAMsr+YGf7=Tj6Vv3oyqjCpk4Q0pzQawrexSwxpJgfyef8sdd1w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 28 August 2017 at 14:56, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

>
> I find myself regurgitating the incantation
>>
>> psql -qAtX -v ON_ERRORS_STOP=1
>>
>> quite a bit. It's not ... super friendly.
>>
>> It strikes me that we could possibly benefit from a 'psql --batch' option.
>>
>> Thoughts?
>>
>
> The link between -qAtX and "batch" is not that fully obvious, especially
> the unaligned tuples-only part. If so, why not some -F <tab> as well?
>
>
q: quiet

Pretty much always wanted for a batch mode run of anything.

A: unaligned tuples

Because alignment is pretty much never useful when you're parsing result
sets with scripting (splitting, cut, etc) and just makes everything harder.
The alignment psql uses isn't fixed, after all.

t: tuples-only

Headers just make everything more annoying to parse, and force you to do
extra work to skip them. If you're running batch code you know the headers
because you used a column-list form SELECT, or should've. You're unlikely
to be ingesting them and using them to split up the tuple anyway. I think
this one is a bit more arguable than the first two, though, as I can at
least think of some cases where you might want it.

X: skip .psqlrc

Reliable, portable scripted psql shouldn't be using the local .psqlrc IMO.
It's likely to just break things in exciting ways. But I can see it being
reasonable to require this option to be supplied separately and just
document it as "recommended" with --batch.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message yangjie@highgo.com 2017-08-28 07:05:37 Re: hash partitioning based on v10Beta2
Previous Message Alvaro Herrera 2017-08-28 06:57:52 Re: Re: Poor cost estimate with interaction between table correlation and partial indexes