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