Re: Error message inconsistency

From: Greg Steiner <greg(dot)steiner89(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Error message inconsistency
Date: 2019-03-24 13:41:01
Message-ID: CABGrpzB2qB3fPfNFj5dyLpt_B98UBRxW5mmAZXzJR2-LfRDv+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

To me the error message that includes more detail is superior. Even though
you can get the detail from the logs, it seems like it would much more
convenient for it to be reported out via the error to allow
users/applications to identify the problem relation without fetching logs.
I understand if that's not worth breaking numerous tests, though.
Personally, I think consistency here is important enough to warrant it.

On Sun, Mar 24, 2019, 9:02 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Sat, Mar 23, 2019 at 4:33 AM Fabrízio de Royes Mello
> <fabriziomello(at)gmail(dot)com> wrote:
> >
> > On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs <simon(at)2ndquadrant(dot)com>
> wrote:
> > >
> > > As noted by a PostgreSQL user to me, error messages for NOT NULL
> constraints are inconsistent - they do not mention the relation name in the
> message, as all other variants of this message do. e.g.
> > >
> > > postgres=# create table nn (id integer not null);
> > > CREATE TABLE
> > > postgres=# insert into nn values (NULL);
> > > ERROR: null value in column "id" violates not-null constraint
> > > DETAIL: Failing row contains (null).
> > >
> > > postgres=# create table nn2 (id integer check (id is not null));
> > > CREATE TABLE
> > > postgres=# insert into nn2 values (NULL);
> > > ERROR: new row for relation "nn2" violates check constraint
> "nn2_id_check"
> > > DETAIL: Failing row contains (null).
> > >
> > > I propose the attached patch as a fix, changing the wording (of the
> first case) to
> > > ERROR: null value in column "id" for relation "nn" violates not-null
> constraint
> > >
>
> I think we are inconsistent for a similar message at a few other
> places as well. See, below two messages:
>
> column \"%s\" contains null values
> column \"%s\" of table \"%s\" contains null values
>
> If we decide to change this case, then why not change another place
> which has a similar symptom?
>
> > > It causes breakage in multiple tests, which is easy to fix once/if we
> agree to change.
> > >
> >
> > I totally agree with that change because I already get some negative
> feedback from users about this message too.
> >
>
> What kind of negative feedback did you get from users? If I see in
> the log file, the message is displayed as :
>
> 2019-03-24 18:12:49.331 IST [6348] ERROR: null value in column "id"
> violates not-null constraint
> 2019-03-24 18:12:49.331 IST [6348] DETAIL: Failing row contains (null).
> 2019-03-24 18:12:49.331 IST [6348] STATEMENT: insert into nn values
> (NULL);
>
> So, it is not difficult to identify the relation.
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-03-24 14:12:58 Re: CPU costs of random_zipfian in pgbench
Previous Message Alexander Korotkov 2019-03-24 13:35:13 Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock