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 15:18:06
Message-ID: AANLkTi=_QQk7cB8kYbB4ge5fdpj8Wq=dfT8xCFKyNUpX@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 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.
>
> +1
>
> 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...
but it was rejected and was proposed to cache OIDs on client side.
It is right approach, IMO.

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.

>
> best regards,
> Florian Pflug
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
// Dmitriy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2010-12-15 15:23:12 Re: hstores in pl/python
Previous Message Tom Lane 2010-12-15 15:17:01 Re: Complier warnings on mingw gcc 4.5.0