Re: psql - add special variable to reflect the last query status

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql - add special variable to reflect the last query status
Date: 2017-09-05 19:06:54
Message-ID: alpine.DEB.2.20.1709052102410.17848@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>>> * It might be better if SQLSTATE and ERROR_MESSAGE were left
>>> unchanged by a non-error query.
>
>> Hmmm. I'm not sure. If so, ERROR_MESSAGE should be LAST_ERROR_MESSAGE
>> maybe? Then what about LAST_ERROR_SQLSTATE to go with it, and let SQLSTATE
>> & ERROR_MESSAGE reflect the last command, and ERROR is just the boolean to
>> test if it occured?
>
>>> That would reduce the need to copy them into other variables just
>>> because you needed to do something else before printing them. It'd save
>>> a few cycles too.
>
>> Well, my suggestion would mean that they would be copied when an error
>> occurs, but only when it occurs, which would not be often.
>
> Uh ... what?

Sorry if my sentence was not very clear. Time to go do bed:-)

I just mean that a LAST_ERROR_* would be set when an error occurs. When
there is no error, it is expected to remain the same, and it does not cost
anything to let it as is. If an error occured then you had a problem, a
transaction aborted, paying to set a few variables when it occurs does not
look like a big performance issue. Script usually expect to run without
error, errors are rare events.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-09-05 19:08:50 Re: assorted code cleanup
Previous Message Daniel Gustafsson 2017-09-05 19:04:57 Re: A note about debugging TAP failures