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 ;-)
> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers