On Mon, Sep 24, 2012 at 9:18 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I think this is fundamentally wrong, or at least misleading, because it >> documents OID as if it were an ordinary column. Somebody who did >> "select * from pg_class" and didn't see any "oid" in the result would >> think the docs were wrong. > > Given that it's been quite some time since we defaulted to including > OIDs in tables, and the high level of confusion that individuals trying > to join pg_class and pg_namespace together go through due to select * > not including the oid column, I wonder if perhaps we should consider > changing that. Might be possible to do for just the catalog tables (to > minimize the risk of breaking poorly-written applications), or provide > a GUC to control including the oid column in select *. > >> It's possible that it's worth expending a boilerplate paragraph in each >> of those pages to say "this catalog has OIDs" (or that it doesn't). >> But this isn't the way. > > I'm afraid I disagree with this. The oid column, in the system > catalog, is user-facing and I like having it included as a column in the > table in the docs, so users know what to use when doing joins.
+1. -- 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