Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Date: 2017-02-06 20:27:40
Message-ID: alpine.DEB.2.20.1702062104291.8133@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Consolidated Fabien's TAP test additions with v7, in case anyone else wants
> to be reviewing.

Patch applies (with "patch"), make check ok, psql tap test ok.

I did some more tests. I found a subtlety that I missed before: when
running under ON_ERROR_STOP, messages are not fully consistent:

sh> cat test.sql
\set ON_ERROR_STOP on
\if error
\echo NO
\endif
\echo NO

sh> ./psql < test.sql
SET
# ok
unrecognized value "error" for "\if <expr>": boolean expected
# ok
new \if is invalid, ignoring commands until next \endif
# hmmm... but it does not, it is really stopping immediately...
found EOF before closing \endif(s)
# no, it has just stopped before EOF because of the error...

Also I'm not quite sure why psql decided that it is in interactive mode
above, its stdin is a file, but why not.

The issue is made more explicit with -f:

sh> ./psql -f test.sql
SET
psql:test.sql:2: unrecognized value "error" for "\if <expr>": boolean expected
psql:test.sql:2: new \if is invalid, ignoring commands until next \endif
psql:test.sql:2: found EOF before closing \endif(s)

It stopped on line 2, which is expected, but it was not on EOF.

I think that the message when stopping should be ", stopping as required
by ON_ERROR_STOP" or something like that instead of ", ignoring...", and
the EOF message should not be printed at all in this case.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-02-06 20:28:05 Re: pg_sequences bug ?
Previous Message Christoph Berg 2017-02-06 19:54:13 Re: One-shot expanded output in psql using \gx