Re: wrong relkind error messages

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wrong relkind error messages
Date: 2020-04-14 22:36:25
Message-ID: 20200414223625.GA26246@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Apr-14, Michael Paquier wrote:

> On Mon, Apr 13, 2020 at 11:13:15AM -0400, Tom Lane wrote:

> > ERROR: cannot define statistics for relation "ti"
> > DETAIL: This operation is not supported for indexes.
> >
> > which still leaves implicit that "ti" is an index, but probably that's
> > something the user can figure out.
> >
> > Maybe someone else can do better?
>
> "This operation is not supported for put_relkind_here \"%s\"."? I
> think that it is better to provide a relation name in the error
> message (even optionally a namespace). That's less to guess for the
> user.

But the relation name is already in the ERROR line -- why do you care so
much about also having it in the DETAIL? Besides, I think part of the
point Tom was making is that if you say "not supported for the index
foo" is that the user is left wondering whether the operation is not
supported for that particular index only or for any index.

Tom's other proposal

> > DETAIL: "ti" is an index, and this operation is not supported for that kind of relation.

addresses that problem, but seems excessively verbose.

Also, elsewhere Peter said[1] that we should not try to list the things
that would be allowed, so it's pointless to try to list the relkinds for
which the operation is permissible.

So I +1 this idea:

ERROR: cannot define statistics for relation "ti"
DETAIL: This operation is not supported for indexes.

[1] https://www.postgresql.org/message-id/1293803569.19789.6.camel%40fsopti579.F-Secure.com

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-04-14 22:39:26 Re: pg_basebackup, manifests and backends older than ~12
Previous Message David G. Johnston 2020-04-14 22:28:13 Re: Poll: are people okay with function/operator table redesign?