Re: hstores in pl/python

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Jan Urbański <wulczer(at)wulczer(dot)org>
Cc: Dmitriy Igrishin <dmitigr(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hstores in pl/python
Date: 2010-12-15 16:07:24
Message-ID: 752C11C8-4366-415B-BE13-FB63668441B8@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec15, 2010, at 16:34 , Jan Urbański wrote:
> On 15/12/10 16:25, Dmitriy Igrishin wrote:
>> 2010/12/15 Jan Urbański <wulczer(at)wulczer(dot)org>
>>> So how about just adding a text column to pg_type and a IDENTIFIER
>>> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it
>>> pushing the argument to the extreme? Someone can change around bool and
>>> text type oids, too... And then hstore_plpython looks up the well-known
>>> identifier, sets up a RVV with the OID and everyone's happy.
>>>
>> How IDENTIFIER differs from name ? org.postgresql.hstore vs hstore ?
>
> Hm, now that I think of it, the only real difference is that you don't
> use search_path to look it up. So public.hstore is just as good an
> identifier...

Not if CREATE EXTENSION allows you install hstore into an arbitrary schema.
For pl/python's purposes, requiring the DBA to set plpython_hstore_type
accordingly might work, but clients need to be able to reliably find hstore
too. For them, having to specify the schema of every non-core type your
database adapter might support isn't exactly ideal...

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-15 16:12:17 Re: Complier warnings on mingw gcc 4.5.0
Previous Message Florian Pflug 2010-12-15 15:57:57 Re: CommitFest wrap-up