From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Karl O(dot) Pinc" <kop(at)meme(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Doc patch to note which system catalogs have oids |
Date: | 2012-09-25 01:18:00 |
Message-ID: | 20120925011800.GJ1267@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.
Including something in the boilerplate about it not being shown by
default (or in the description in the table) might be alright, if we
don't change that.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-25 01:24:05 | Re: Oid registry |
Previous Message | Rural Hunter | 2012-09-25 00:41:19 | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |