| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Joe Conway <joseph(dot)conway(at)home(dot)com>, Postgresql General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Partial indices almost there |
| Date: | 2001-07-11 14:00:17 |
| Message-ID: | 18094.994860017@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Does somewhere check for duplicate oids?
The duplicate_oids script in the same directory.
In practice, what really matters is that no two entries in the same
system catalog have the same OID; it wouldn't matter if we had, say,
the same OID used by a pg_proc and a pg_am entry. In some catalogs
it doesn't matter at all because we never do lookups by OID (this is
true for pg_attribute, for example *). We have a unique index on OID
on every system catalog where it matters, and ultimately that is what
ensures validity of the OID assignments. Keeping the hand-assigned
OIDs unique across the whole system is just a matter of neatnik-ism.
regards, tom lane
* In fact, Patricia Holben noticed awhile back that there *are*
duplicate OIDs in pg_attribute, in all releases <= 7.1. This was caused
by a bug in the code that creates pg_attribute rows for multi-key
indexes: it put the same OID on each such row. This is fixed in current
sources, but it's graphic proof that nonunique OIDs don't hurt when
they're not being used for lookup...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-07-11 14:14:17 | Re: Partial Indices vs. mixing columns and functions |
| Previous Message | Olivier Chapiteau | 2001-07-11 13:40:57 | dropping sequence with the table |