Re: Alternative to \copy in psql modelled after \g - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Alternative to \copy in psql modelled after \g
Date
Msg-id d9c67af7-48f2-45ba-b136-f121476267e8@manitou-mail.org
Whole thread Raw
In response to Re: Alternative to \copy in psql modelled after \g  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
    Fabien COELHO wrote:

> (1) document ERROR as being muddy, i.e. there has been some error which
> may be SQL or possibly client side. Although SQLSTATE would still allow to
> know whether an SQL error occured, there is still no client side
> expressions, and even if I had moved pgbench expressions to psql they
> would still need to be extended to handle strings. This suggest that maybe
> there could be an SQL_ERROR boolean which does store whether SQL succeeded
> or not, and possibly a CLIENT_ERROR on the side, and ERROR = SQL_ERROR OR
> CLIENT_ERROR.
>
> (2) keep ERROR as is, i.e. about SQL, and add some CLIENT_ERROR, but then
> I see another issue, if it is *only* the client error, then it should be
> true if there is an SQL error, thus checking if there is any error becomes
> ERROR OR CLIENT_ERROR, which is muddy as well especially as there are no
> client-side expressions in psql.

(3) Set ERROR=true if ON_ERROR_STOP would quit on the exact same
conditions.

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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Procedures with out parameter(Postgresql 11)
Next
From: Andreas Karlsson
Date:
Subject: Re: Early WIP/PoC for inlining CTEs