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" ? Cheers -- 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: http://www.postgresql.org/mailpref/pgsql-hackers
