and it's not a bunny rabbit, either

In reviewing the work Shigeru Hanada has done on SQL/MED, it's come to
my attention that we have a lot of error messages that use the error
code ERRCODE_WRONG_OBJECT_TYPE and have text like this:

"%s" is not a table
"%s" is not an index

or even better:

"%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

If we someday add materialized views, it'll need to mention that, too.
In the particular case I'm looking at right now (renameatt_internal),
a more informative error message might be something like
"system-generated attribute names may not be altered", and maybe
that's actually a good way to go in that particular case. But it
seems somewhat painful to make this work for ATSimplePermissions() and
ATSimplePermissionsRelationOrIndex(); in many cases, there's not much
to say beyond the fact that the particular alter table subcommand
isn't supported by the object type to which the user has attempted to
apply it. Still, I'm a bit wondering if there's some more generic way
we can phrase the problem.

Could we get away with something as simple as "requested operation is
not supported for <plural-form-of-object-type>"? In some sense that's
less informative, because it doesn't tell you which object types DO
support the requested operation, but it's not clear that you care
about that. If you are trying to drop a column from a view, the fact
that it would be possible to drop a column from a table is cold
comfort. The advantage of this method is that you need only N
translatable strings (one per relkind), rather than 2^N (one per
subset of the universe of relkinds).

A slightly more granular version of this would be to make the caller
pass in a string indicating what the requested operation actually is,
so that you can say something like "<plural-form-of-object-type> do
not support <requested-operation>" or "<requested-operation> is not
supported by <plural-form-of-object-type>" (e.g. "views do not support
SET NOT NULL"). But that breaks our guideline about assembling
translatable strings from small pieces. Maybe it'd be OK if the piece
is just a fragment of SQL syntax, though - not sure.

Or we can just stick with the way we've been doing it, if I'm the only
one who thinks it's icky.

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