Re: Feature request - CREATE TYPE ... WITH OID = oid_number.
От | Pavel Stehule |
---|---|
Тема | Re: Feature request - CREATE TYPE ... WITH OID = oid_number. |
Дата | |
Msg-id | AANLkTinthmoZ4O=xnAfYq0bsjX29yAwHW4BxqEKQF3Kv@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Feature request - CREATE TYPE ... WITH OID = oid_number. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Feature request - CREATE TYPE ... WITH OID = oid_number.
|
Список | pgsql-hackers |
2010/12/7 Tom Lane <tgl@sss.pgh.pa.us>: > Merlin Moncure <mmoncure@gmail.com> writes: >> On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane <tgl@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 >
В списке pgsql-hackers по дате отправления: