Re: [PATCH] Partial indices almost there

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: Raw Message | Whole Thread | 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...

In response to

Browse pgsql-general by date

  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