On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
>> 2010/12/15 Florian Pflug <fgp@phlo.org>
>> On Dec15, 2010, at 02:14 , James William Pye wrote:
>> > On Dec 13, 2010, at 6:16 PM, Tom Lane wrote:
>> >> how do you identify which type OID is really hstore?
>> >
>> > How about an identification field on pg_type?
>> >
>> > CREATE TYPE hstore ..., IDENTIFIER 'org.postgresql.hstore';
>> > -- Where the "identifier" is an arbitrary string.
>>
>> I've wanted something like this a few times when dealing
>> with custom types within a client. A future protocol version
>> might even transmit these identifiers instead a the type's OID,
>> thereby removing the dependency on OID from clients entirely.
>
> In some another tread I've proposed CREATE TYPE ... WITH OID...
Yeah, and I believe type identifiers are probably what you were
really looking for ;-)
> but it was rejected and was proposed to cache OIDs on client side.
> It is right approach, IMO.
Yes, but to cache OIDs you first have to find them. As long as their
name and schema are known, thats easy, but once they aren't you're
pretty much screwed.Since CREATE EXTENSION is going to let you
install an extension into any schema you want, not knowing the schema
is going to be pretty common, I believe. Type identifiers would solve
this, by providing an easy and unambiguous way to find specific types.
> But, IMO, comparing strings to determine type for each parameter
> is not very good idea because it is not so efficient as comparing
> integers, obviously.
That's maybe an argument against a possible future protocol version
that'd transfer type identifiers instead of OIDS. But not against
associating type identifiers with types in the first place, since
after your initial lookup you'd still be comparing OIDs.
best regards,
Florian Pflug