Re: and it's not a bunny rabbit, either

On Sun, Dec 26, 2010 at 10:13:35PM -0500, Robert Haas wrote:
> 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>"?

+1 for this.  It's clear, informative, and relevant to the error at
hand.

> 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.

You're not the only one.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate