2010/12/15 Florian Pflug <f...@phlo.org> > On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote: > >> 2010/12/15 Florian Pflug <f...@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.
