On 11/20/2013 10:58 PM, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut <pete...@gmx.net> wrote:
>> This is a transition problem.  Nobody is required to install the
>> transforms into their existing databases.  They probably shouldn't.
> Sure, but that's like saying "nobody's required to use this
> behavior-changing GUC, so it's OK to have a behavior-changing GUC".
> The point I think Dimitri is making, which IMHO is entirely valid, is
> that the feature as currently designed is database-wide.  You either
> get this behavior for all of your functions, or you get it for none of
> them, and that might well not be what you want.  For example, it's
> easy to imagine that you might want to install extensions A and B.  A
> expects that a certain transform is loaded into the database, and B
> expects that it isn't.  You now have created a situation where
> extensions A and B can't be used together.  That sucks.
> If the transform were a property of particular function argument
> positions, this wouldn't be a problem.  You could declare, in effect,
> that a certain function takes a transformed hstore, and this other one
> takes a non-transformed hstore.  Now life is good.  But that's not
> what is being proposed.
You mean something like

CREATE FUNCTION f(i int, h1 hstore USING TRANSFORM x, h2 hstore) ...

where h1 would go through transform x and 1 and h2
would use "default transform" ?


Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to