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