Re: [HACKERS] Macros bundling RELKIND_* conditions

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [HACKERS] Macros bundling RELKIND_* conditions
Дата
Msg-id de750edf-8d85-420f-d03d-8f5027b20379@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Macros bundling RELKIND_* conditions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] Macros bundling RELKIND_* conditions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: [HACKERS] why not parallel seq scan for slow functions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Macros bundling RELKIND_* conditions