Re: Alternative to \copy in psql modelled after \g

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>,"PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>,"David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: Alternative to \copy in psql modelled after \g
Date: 2019-01-21 12:48:32
Message-ID: 529c12d1-fd00-4631-89e7-59e6ef6c46c6@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO wrote:

> sql> SELECT 1 \g /BAD
> /BAD: Permission denied
>
> sql> \echo :ERROR
> false

That seems broken, because it's pointless to leave out a class of errors
from ERROR. Presumably the purpose of ERROR is to enable
error checking like:
\if :ERROR
... error processing
\endif

Now if you download data with SELECT or COPY and we can't even
create the file, how is that a good idea to intentionally have the
script fail to detect it? What purpose does it satisfy?

> The documentation states that ERROR is about SQL, not psql internal stuff:
>
> ERROR true if the last SQL query failed, false if it succeeded.
> See also SQLSTATE.

ERROR is set by SetResultVariables(PGresult *results, bool success)
and takes the value of "success", ignoring the PGresult.
So why is ERROR independant of the SQL result, relatively to your
claim that it should never reflect anything else?

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2019-01-21 12:59:45 Re: Procedures with out parameter(Postgresql 11)
Previous Message navneet nikku 2019-01-21 12:43:03 Procedures with out parameter(Postgresql 11)