2010/12/15 Florian Pflug
<fgp@phlo.org>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 ;-)
Indeed, but why OID cannot serve as identifier in this case ? Why to
encode the code ? :-)
> 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.
Agree.
Type identifiers would solve
this, by providing an easy and unambiguous way to find specific types.
Agree with 1st assertion but disagree with 2nd. If I understand correctly,
"identifier" is a second name for type (object), but Java-styled, right ?
It probably does solve the problem if there are will be convention that
types org.postgresql.* are reserved. But why not reserve name of type
"hstore" and prevent the user to create type with this reserved name ?
All this tells me one thing - to avoid conflicts of naming of specific types
it is necessary to make them built-in.
> 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
--
// Dmitriy.