Re: Oid registry - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Oid registry
Date
Msg-id 5061B266.6060206@dunslane.net
Whole thread Raw
In response to Re: Oid registry  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Oid registry
List pgsql-hackers
On 09/24/2012 11:39 PM, Tom Lane wrote:

> My recollection of the PGCon discussion is that people wanted to allow
> client-side code to hard-wire type OIDs for add-on types, in more or
> less the same way that things like JDBC know that "25" is "text".
> That's not unreasonable, since the alternatives are complicated and
> not all that reliable.  I'm not sure the usage applies to anything
> except data types though, so at least for starters I'd only want to
> accept reservations of OIDs for data types.
>
>             

Yes, I certainly think that's a sufficient case. And just to be clear, I 
don't care about the "private range" suggestion. I was just reporting 
that as it came up in the discussion and at least wasn't immediately 
shouted down. But I'm happy to abandon it at least for now. If there is 
ever actual demand for it we could revisit the matter.

Given your previous comments, perhaps we could just start handing out 
Oids (if there is any demand) numbered, say, 9000 and up. That should 
keep us well clear of any existing use.

Regarding the use of pre-allocated Oids, unless we provide some facility 
to use them when creating types extension authors will be reduced to 
using the pretty ugly tricks I had to use when backporting JSON for 
binary upgrade-ability. This used some of pg_upgrade's tricks to force 
use of particular Oids, but I don't think this should be recommended 
practice. The suggestion I made was based on something you suggested 
(albeit with some caveats) in the recent discussion of pg_upgrade with 
extensions.

cheers

andrew




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Patch for option in pg_resetxlog for restore from WAL files
Next
From: Brian Weaver
Date:
Subject: Re: Patch: incorrect array offset in backend replication tar header