2010/12/7 Tom Lane <t...@sss.pgh.pa.us>: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Say what? He didn't say that, he said "don't assume that user-defined >>> types have hard-wired OIDs". > >> Well, you're right, strictly speaking. Of course, the OP is not >> assuming it, he is enforcing it. > > No, he's wishing he could enforce it. Which will work, mostly, until > the day it doesn't because of a pre-existing collision. And then he'll > be up the creek with a lot of software that he can't fix readily. I > concur with Andrew's advice: don't go there in the first place. Use a > cache to mitigate the costs of looking up user-defined OIDs, and you > won't regret it later. >
I had to solve similar task, and probably I am not alone. Can pg supports some cache and some API for "custom oid"? Now, a work with custom types on C level is little bit unfriendly. There isn't a problem with builtin types - these are well defined. I agree, so direct access to oids for custom types isn't a good idea. But some general API or pattern can be nice - mainly for client side. regards Pavel > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers