Thread: BUG #12721: psql -a does not preserve empty lines between SELECTs

The following bug has been logged on the website:

Bug reference:      12721
Logged by:          Hans Ginzel
Email address:      hans@matfyz.cz
PostgreSQL version: 9.4.0
Operating system:   GNU/Linux Centos 6.5
Description:

Hello!

There is, in the [doc] that psql with option -a echoes all input lines.

Try a file containing
SELECT count(*) AS N FROM information_schema.Tables;

SELECT count(*) AS N FROM information_schema.Columns;

There is an empty line between SELECTs and they are each on one line. The
output of
    cat input.sql |psql -naAF"`echo -e '\t'`" -Pfooter=off
is in my case is

SELECT count(*) AS N FROM information_schema.Tables;
n
205
SELECT count(*) AS N FROM information_schema.Columns;
n
1855

The empty line has disappeared. If there had been a comment line, it would
have been preserved. Preserve also empty lines, please.

[doc]: http://www.postgresql.org/docs/9.4/static/app-psql.html

Best regards
HG

PS: Please, is there a better way how to specify tab as delimiter?

hans@matfyz.cz writes:
> There is, in the [doc] that psql with option -a echoes all input lines.

Hm.  That's poorly phrased: what it actually echoes is commands, not
lines.  This must be so because some of the other possible settings of
ECHO require decisions at the per-command level.  I will see about
improving the wording here.

> The empty line has disappeared. If there had been a comment line, it would
> have been preserved. Preserve also empty lines, please.

Sorry, that's not going to happen.  psql has always stripped whitespace
appearing before a command, and changing that would create a lot of
unhappiness in a lot of other behaviors.

> PS: Please, is there a better way how to specify tab as delimiter?

Maybe put \pset fieldsep '\t' in the input .sql file, instead of setting
it up on the command line.

            regards, tom lane

I wrote:
> hans@matfyz.cz writes:
>> There is, in the [doc] that psql with option -a echoes all input lines.

> Hm.  That's poorly phrased: what it actually echoes is commands, not
> lines.  This must be so because some of the other possible settings of
> ECHO require decisions at the per-command level.

Huh --- I take that back; the "queries" and "errors" cases are implemented
totally independently of "all" mode.  The "all" mode does work on a line
by line basis, and there's no good reason why it doesn't print blank
lines, except that somebody wasn't thinking very hard about where they
added the test.  Will fix.

The documentation is wrong too, but not in the way I thought; it should
say that interactive input is never echoed by this feature, rather than
that it's "less useful" to turn it on for that.

            regards, tom lane

I wrote:
> Huh --- I take that back; the "queries" and "errors" cases are implemented
> totally independently of "all" mode.  The "all" mode does work on a line
> by line basis, and there's no good reason why it doesn't print blank
> lines, except that somebody wasn't thinking very hard about where they
> added the test.  Will fix.

Or maybe not.  It's a simple enough change, but it breaks all our
regression tests, which use -a and are not expecting blank lines to
get echoed.  So I think I was right the first time: the existing behavior
is probably embedded in enough places that changing it would not be worth
the pain.  Sorry.

> The documentation is wrong too, but not in the way I thought; it should
> say that interactive input is never echoed by this feature, rather than
> that it's "less useful" to turn it on for that.

This still needs fixed though ...

            regards, tom lane

Thank you, Tom.

On Sat, Jan 31, 2015 at 01:35:00PM -0500, Tom Lane wrote:
>> PS: Please, is there a better way how to specify tab as delimiter?
>Maybe put \pset fieldsep '\t' in the input .sql file, instead of setting
>it up on the command line.

I have SELECTs on stdin and everything others should be set on command line.
I have reported a specific bug about that. See #12725.

Regards,
Hans