2015-03-17 2:51 GMT+01:00 Peter Eisentraut <pete...@gmx.net>: > On 3/12/15 8:12 AM, Pavel Stehule wrote: > > 1. fix missing semicolon pg_proc.h > > > > Oid protrftypes[1]; /* types for which to apply > > transforms */ > > Darn, I thought I had fixed that. > > > 2. strange load lib by in sql scripts: > > > > DO '' LANGUAGE plperl; > > SELECT NULL::hstore; > > > > use load plperl; load hstore; instead > > OK > > > 3. missing documentation for new contrib modules, > > OK > > > 4. pg_dump - wrong comment > > > > +<-----><------>/* > > +<-----><------> * protrftypes was added at v9.4 > > +<-----><------> */ > > OK > > > 4. Why guc-use-transforms? Is there some possible negative side effect > > of transformations, so we have to disable it? If somebody don't would to > > use some transformations, then he should not to install some specific > > transformation. > > Well, there was extensive discussion last time around where people > disagreed with that assertion. >
I don't like it, but I can accept it - it should not to impact a functionality. > > > 5. I don't understand to motivation for introduction of protrftypes in > > pg_proc and TRANSFORM clause for CREATE FUNCTION - it is not clean from > > documentation, and examples in contribs works without it. Is it this > > functionality really necessary? Missing tests, missing examples. > > Again, this came out from the last round of discussion that people > wanted to select which transforms to use and that the function needs to > remember that choice, so it doesn't depend on whether a transform > happens to be installed or not. Also, it's in the SQL standard that way > (by analogy). > > I am sorry, I didn't discuss this topic and I don't agree so it is good idea. I looked to standard, and I found CREATE TRANSFORM part there. But nothing else. Personally I am thinking, so it is terrible wrong idea, unclean, redundant. If we define TRANSFORM, then we should to use it. Not prepare bypass in same moment. Can be it faster, safer with it? I don't think. Regards Pavel
