Re: hstores in pl/python

From: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: James William Pye <lists(at)jwp(dot)name>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jan Urbański <wulczer(at)wulczer(dot)org>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hstores in pl/python
Date: 2010-12-15 18:22:56
Message-ID: AANLkTi=HmtWuJyutNu6W4E_ATE7QHmQyWk2Fp=oTO-+-@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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...

>
> best regards,
> Florian Pflug
>
>
>

--
// Dmitriy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniele Varrazzo 2010-12-15 18:25:01 getting composite types info from libpq
Previous Message Robert Haas 2010-12-15 18:05:26 Re: Segfault related to pg_authid when running initdb from git master