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.
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 |