Re: and it's not a bunny rabbit, either - Mailing list pgsql-hackers

On Thu, Dec 30, 2010 at 8:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On further reflection, this can still turn into a laundry list in certain cases.
>
>> DETAIL: You can only comment on columns of tables, views, and composite types.
>
>> seems less helpful than:
>
>> DETAIL: Comments on relations with system-generated column names are
>> not supported.
>
>> I think that for rules, triggers, constraints, and anything that only
>> works on a single relkind, we can't do much better than to list the
>> specific object types.  But where there's some sort of guiding
>> principle involved I think we'd do well to articulate it.
>
> I'm unconvinced, because the "guiding principle" is likely to be an
> implementation detail that won't actually mean much to users.  Your
> example above is a case in point --- I do *not* think the average
> user will see that as an improvement.

I think this thread has worked itself around to where it's entirely
pointless.  My original complaint was about error messages like this:

"%s" is not a table, view, composite type, or index

which, once we have foreign tables, needs to be changed to read:

"%s" is not a table, view, composite type, index, or foreign table

I think that message is the epitome of worthless, and several other
people agreed.  After various proposals of greater and lesser merit,
we've somehow worked around to the suggestion that this should be
reworded to:

ERROR: "%s" is a sequence
DETAIL: Only attributes of tables, views, composite types, indexes, or
foreign tables can be renamed.

While that may be a marginal improvement in clarity, it does
absolutely nothing to address my original complaint, which is that
adding a relkind forces trivial revisions of messages all over the
system, some of which are already excessively long-winded.  This
message also does nothing to help the user understand WHY we don't
allow renaming the attributes of his sequence or TOAST table, whereas
the proposed revision does.

The absolute worst offenders are messages of the form:

<blah> is not supported on X, Y, Z, or T.

which now have to be revised to read:

<blah> is not supported on X,Y, Z, T, or W.

This problem could be avoided by writing:

<blah> is supported on A and B

Or:

<blah> is supported only for relation types which quack

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company