Re: Add schema-qualified relnames in constraint error messages. - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Add schema-qualified relnames in constraint error messages.
Date
Msg-id cb00e750-3883-4362-b029-5605bc0dc3fe@mm
Whole thread Raw
In response to Re: Add schema-qualified relnames in constraint error messages.  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
Responses Re: Add schema-qualified relnames in constraint error messages.
List pgsql-hackers
Shulgin, Oleksandr wrote:

> Added to the Open commitfest: https://commitfest.postgresql.org/9/475/

Here's a review. Note that the patch tested and submitted
is not the initial one in the thread, so it doesn't exactly
match  $subject now.
What's tested here is a client-side approach, suggested by Tom
upthread as an alternative, and implemented by Oleksandr in
0001-POC-errverbose-in-psql.patch

The patch has two parts: one part in libpq exposing a new function
named PQresultBuildErrorMessage, and a second part implementing an
\errverbose command in psql, essentially displaying the result of the
function.
The separation makes sense if we consider that other clients might benefit
from the function, or that libpq is a better place than psql to maintain
this in the future, as the list of error fields available in a PGresult
might grow.
OTOH maybe adding a new libpq function just for that is overkill, but this
is subjective.

psql part
=========
Compiles and works as intended.
For instance with \set VERBOSITY default, an FK violation produces:
 # insert into table2 values(10); ERROR:  insert or update on table "table2" violates foreign key constraint
"table2_id_tbl1_fkey"DETAIL:  Key (id_tbl1)=(10) is not present in table "table1". 

Then \errverbose just displays the verbose form of the error: # \errverbose   ERROR:  23503: insert or update on table
"table2"violates foreign     key constraint "table2_id_tbl1_fkey"   DETAIL:  Key (id_tbl1)=(10) is not present in table
"table1".  SCHEMA NAME:  public   TABLE NAME:  table2   CONSTRAINT NAME:  table2_id_tbl1_fkey   LOCATION:
ri_ReportViolation,ri_triggers.c:3326 

- make check passes
- valgrind test is OK (no obvious leak after using the command).

Missing bits:
- the command is not mentioned in the help (\? command, see help.c)
- it should be added to tab completions (see tab-complete.c)
- it needs to be described in the SGML documentation

libpq part
==========
The patch implements and exports a new PQresultBuildErrorMessage()
function.

AFAICS its purpose is to produce a result similar to what
PQresultErrorMessage() would have produced, if PQERRORS_VERBOSE
was the verbosity in effect at execution time.

My comments:

- the name of the function does not really hint at what it does.
Maybe something like PQresultVerboseErrorMessage() would be more
explicit?

I would expect the new function to have the same interface than
PQresultErrorMessage(), but it's not the case.

- it takes a PGconn* and PGresult* as input parameters, but
PQresultErrorMessage takes only a <const PGresult*> as input.
It's not clear why PGconn* is necessary.

- it returns a pointer to a strdup'ed() buffer, which
has to be freed separately by the caller. That differs from
PQresultErrorMessage() which keeps this managed inside the
PGresult struct.

- if protocol version < 3, an error message is returned. It's not
clear to the caller that this error is emitted by the function itself
rather than the query. Besides, are we sure it's necessary?
Maybe the function could just produce an output with whatever
error fields it has, even minimally with older protocol versions,
rather than failing?

- if the fixed error message is kept, it should pass through
libpq_gettext() for translation.

- a description of the function should be added to the SGML doc.
There's a sentence in PQsetErrorVerbosity() that says, currently:
 "Changing the verbosity does not affect the messages available from  already-existing PGresult objects, only
subsequently-createdones." 

As it's precisely the point of that new function, that bit could
be altered to refer to it.


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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Use %u to print user mapping's umid and userid
Next
From: Joe Conway
Date:
Subject: Re: [ADMIN] 9.5 new setting "cluster name" and logging