On 11/20/2013 10:58 PM, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 11:51 AM, Peter Eisentraut <peter_e@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" ?
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
