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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
