From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pg(at)fastcrypt(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_type oid's do they change from version to version |
Date: | 2004-05-20 02:58:32 |
Message-ID: | 24599.1085021912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
>> I don't think we have ever changed oids for existing data types, so you
>> should be OK.
> Are you sure? If we remove a type, then its oid becomes up for grabs by
> the unused_oids script.
But if we remove a type then it's a bit moot whether the OID for it
stays constant. For types that have remained present across all
versions I don't think we have ever changed the OID assignment.
I'd be willing to promise that this will stay true for the types
that are "manually" declared in pg_type.h. (As a counterexample,
I think that information_schema.sql creates some domain types, and
those types aren't going to have frozen OIDs.)
> I think the core should mandate it as policy never to reuse oids and
> perhaps make the unused_oids script "remember" what has been used...
Absolutely not worth the trouble. If we were to guarantee not to remove
types, then there might be some value in making such a promise, but we
haven't and won't. (Precedent: the SQL spec itself has added and
dropped datatypes.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-05-20 02:58:51 | Re: Clustering system catalog indexes |
Previous Message | Tom Lane | 2004-05-20 02:32:50 | Re: Join works in 7.3.6, fails in 7.4.2 |