Re: hstores in pl/python

2010/12/15 Florian Pflug <fgp(at)phlo(dot)org>

> On Dec15, 2010, at 16:18 , Dmitriy Igrishin wrote:
> >> 2010/12/15 Florian Pflug <fgp(at)phlo(dot)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.