On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > It would make dependency error messages significantly longer and less > readable. Quite aside from the point at hand here, we elide schema > names in many cases (and it looks like there are some code paths where > getObjectDescription never bothers to print them at all). Another issue > that might make it interesting to try to use the output for purposes > other than human-readable descriptions is that we localize all the > phrases involved. > > My point is that this isn't a bug fix, it's more like moving the > goalposts on what getObjectDescription is supposed to do. And I'm not > even very sure where they're being moved to. I haven't seen a > specification for an intended use of pg_describe_object for which its > existing behavior would be unsatisfactory.
I think that adding the types to the description string is a pretty sensible thing to do. Yeah, it makes the error messages longer, but it also tells you which objects you're actually operating on, a non-negligible advantage. It's fairly confusing that pg_amproc has a four part key, two members of which reference objects which in turn have compound names. But leaving out two out of the four parts in the key is not an improvement. People aren't going to hit dependencies on pg_amproc entries every day, but when they do they presumably want to uniquely identify the objects in question. Now, I agree that this is probably not quite adequate to the purpose to which the OP proposed to put it, but that's really another question. One gripe I do have is that we should put the operator types in the same place ALTER OPERATOR FAMILY puts them - immediately after the support number, and without the word "for" - rather than all the way at the end. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
