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 could argue that such a level of granularity is overkill, but frankly I've never had a real good feeling about the likelihood of these transforms getting installed in the first place. In theory, if you're using hstore and you're using plperl, you ought to also install hstore-plperl-transform, but I bet a significant percentage of people won't. So I don't foresee a finite transition period after which databases without transforms go away and all code is written with the assumption that transforms are available; instead, I foresee different people assuming different things and ending up with mutually incompatible code bases. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
