On Tue, Dec 7, 2010 at 12:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
That problem is theoretical as long as you are aware of it and defend
against it properly. Which I do. Also a client side maintained cache
doesn't do squat if you want to transfer data between databases in
binary, which I suppose is another thing I'm not to be doing (nor
would I advise others to do it without disclaiming the risks). Not to
mention, maintaining a cache is harder than it sounds and is not a
route I'd suggest taking either for the most part. We don't even
expose pg_types.h to libpq.
OK, I understand your and Andrew's point of views here. The safest
path is generally the best path. That said, I and other users are
trying to do things that really ought to be able to be done. Short of
replacing oids with type names in the wire format (probably
unworkable) or pushing some of the type library into the client
(ecpg), we are stuck with the status quo. We are doing very cool
things with the status quo.
merlin