From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com> |
Subject: | Re: Macros bundling RELKIND_* conditions |
Date: | 2017-08-02 17:44:54 |
Message-ID: | de750edf-8d85-420f-d03d-8f5027b20379@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/2/17 13:28, Alvaro Herrera wrote:
> I think pg_class is a reasonable place to put more generic relkind lists
> alongside a matching error message for each, rather than specialized
> "does this relkind have storage" macros. What about something like a
> struct list in pg_class.h,
>
> {
> {
> relkinds_r_i_T,
> { 'r', 'i', 'T' },
> gettext_noop("relation %s is not a table, index or toast table")
> },
> ...
> }
I don't find this style of error message optimal anyway. If I do, for
example
ALTER TABLE someview ADD CONSTRAINT ...
ERROR: "someview" is not a table, foreign table, whatever
then this information is not helpful. It's not like I'm going to turn
my view into a foreign table in order to be able to proceed with that
command. The actual error, from the perspective of the user, is
something like
ERROR: "someview" is a view
DETAIL: Views cannot have constraints.
(Maybe they can. This is an example.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-08-02 17:45:37 | Re: Macros bundling RELKIND_* conditions |
Previous Message | Jeff Janes | 2017-08-02 17:42:40 | Re: why not parallel seq scan for slow functions |