Re: hstores in pl/python

2010/12/15 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>

>
>
> 2010/12/15 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>
> 2010/12/15 Dmitriy Igrishin <dmitigr(at)gmail(dot)com>:
>> >
>> >
>> > 2010/12/15 Florian Pflug <fgp(at)phlo(dot)org>
>> >>
>> >> On Dec15, 2010, at 18:33 , Dmitriy Igrishin wrote:
>> >> > 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 ? :-)
>> >> Because there are only 2^32 OIDs, so if people start picking them at
>> >> random, sooner or later there will be collisions.
>> >
>> > Yes, but range of PostgreSQL's OIDs can be reserved. One or even ten
>> > millions, e.g. can be enough.
>> >
>> >>
>> >> > 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.
>> >> Yeah, that'd be the idea. If everyone uses reversed DNS-style names,
>> and
>> >> everyone picks a name belonging to a DNS zone under his control, there
>> >> cannot be any collisions. At least for java packages, this seems to
>> work
>> >> pretty nicely.
>> >>
>> >> > 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.
>> >> None of these solutions scale well.
>> >
>> > Well, If there are will be identifiers for each type, e.g.
>> > org.postgresql.integer, why
>> > they need to be built-in ? For "historical reasons" ? :-)
>> > Let them also be in contribs...
>>
>> some types are used in system tables, so without support of these
>> types, then you can't to add a new types. It's a egg-chicken problem
>>
> So, the formal criterion to make the type built-in is "the type is must be
> primitive" ?
>
I.e. "the type for deploying system catalogs".

>
>> Pavel
>>
>> >>
>> >> best regards,
>> >> Florian Pflug
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > // Dmitriy.
>> >
>> >
>> >
>>
>
>
>
> --
> // Dmitriy.
>
>
>

--
// Dmitriy.