On Mon, Jun 6, 2011 at 2:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jun 6, 2011 at 1:03 PM, Alvaro Herrera >> <alvhe...@commandprompt.com> wrote: >>> Hmm, if we're going to have pg_comments as a syntactic sugar kind of >>> thing, it should output things in format immediately useful to the user, >>> i.e. relation/column/etc names and not OIDs. The OIDs would force you >>> to do lots of joins just to make it readable. > >> Well, that's basically what this is doing. See the objname/objtype >> columns. It's intended that the output of this view should match the >> format that COMMENT takes as input. But propagating the OIDs through >> is sensible as well, because sometimes people may want to do other >> joins, filtering, etc. > > Is it also propagating the catalog OID through? Because joining on OID > alone is not to be trusted.
Yep. > I tend to agree with Alvaro's viewpoint here: anybody who wants to deal > directly in OIDs is better off joining directly to pg_description, and > not going through the rather large overhead that this view is going to > impose. So we should just make this a purely user-friendly view and be > done with it, not try to create an amalgam that serves neither purpose > well. Possibly. On the other hand we have things like pg_tables floating around that are basically useless because you can't get the OID easily. The information_schema suffers from this problem as well. I get what you're saying, but I think we should think two or three times very carefully before throwing away the OID in a situation where it can easily be provided. -- 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
