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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
