Re: [HACKERS] psql - add special variable to reflect the last querystatus - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] psql - add special variable to reflect the last querystatus
Date
Msg-id alpine.DEB.2.20.1709060958260.17848@lancre
Whole thread Raw
In response to Re: [HACKERS] psql - add special variable to reflect the last query status  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] psql - add special variable to reflect the last querystatus
List pgsql-hackers
Hello Tom,

Here is a version 6.

> A few thoughts about this patch:
>
> * I think the ERROR_CODE variable should instead be named SQLSTATE.
> That is what the SQL standard calls this string, and it's also what
> just about all our documentation calls it; see PG_DIAG_SQLSTATE
> in libpq, or the SQLSTATE 'xxxxx' construct in pl/pgsql, or the
> sqlstate attribute of an exception object in plpython, etc etc.

ERROR_CODE -> SQLSTATE.

> * I'm not exactly convinced that there's a use-case for STATUS

Removed, but I think it was nice to have, it is easier to interpret than 
error codes and their classes that I have not memorized yet:-)

> * It might be better if SQLSTATE and ERROR_MESSAGE were left
> unchanged by a non-error query.  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.

Added LAST_ERROR_SQLSTATE & MESSAGE, only reset when an error occured.

> * Speaking of which, has anyone tried to quantify the performance
> impact of this patch?  It might well be negligible, but I do not
> think we should assume that without evidence.

My guess is negligible. Not sure how to measure this negligible, as many 
very fast query should be executed to have something significant. Maybe 
100,000 "SELECT 1;" in a script?

> * I wonder why you didn't merge this processing into ProcessResult,
> instead of inventing an extra function (whose call site seems rather
> poorly chosen anyhow --- what's the justification for not counting this
> overhead as part of the query runtime?).  You could probably eliminate
> the refactoring you did, since it wouldn't be necessary to recompute
> AcceptResult's result that way.

Variable setting moved at then end of ProcessResult, no new functions,
result is clean, so I should have done it like that in the beginning.

Forgotten help stuff added.

-- 
Fabien.
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?