Re: hstores in pl/python

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, 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 21:41:19
Message-ID: 6BE95CB2-A49D-4795-8153-44A6D31AA1F4@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec15, 2010, at 21:28 , Dimitri Fontaine wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> Not if CREATE EXTENSION allows you install hstore into an arbitrary schema.
>
> It also allows you to change it after the fact, and to easily track it
> down. Here's an updated version of the query to find the hstore type OID
> reliably once we have extensions in:
>
> <snipped SQL>
That's certainly cool, but having to use different methods to find a type
depending on how it has been installed isn't exactly ideal. And not every
user-defined type will be installed via CREATE EXTENSION.

Thus I still believe something like a type identifier that is independent from
it's name and schema would be nice to have.

In case you wonder if than means every object should have such a handle -
they should *not*. What makes types special is that they are used on
the protocol level, not only on the SQL level. Thus, handling them
frequently falls into the real of client libraries, not individual
client applications, making it more important to be able to handle them
in an application-agnostic way.

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitriy Igrishin 2010-12-15 21:47:10 Re: hstores in pl/python
Previous Message Andrew Dunstan 2010-12-15 21:38:08 Re: Complier warnings on mingw gcc 4.5.0