On Jan12, 2014, at 22:37 , Pavel Stehule <pavel.stehule@gmail.com> wrote: > There is GUC for variable_conflict already too. In this case I would to > enable this functionality everywhere (it is tool how to simply eliminate > some kind of strange bugs) so it needs a GUC. > > We have GUC for plpgsql.variable_conflict three years and I don't know > about any problem.
I must say I hate behaviour-changing GUCs with quite some passion. IMHO they tend to cause bugs, not avoid them, in the long run. The pattern usually is
1) Code gets written, depends on some particular set of settings to work correctly
2) Code gets reused, with little further testing since it's supposed to be battle-proven anyway. Settings get dropped.
3) Code blows up for those corner-cases where the setting actually matter. Debugging is hell, because you effectively have to go over the code line-by-line and check if it might be affected by some GUC or another.
Only a few days ago I spent more than an hour tracking down a bug which, as it turned out, was caused by a regex which subtly changed its meaning depending on whether standard_conforming_strings is on or off.
Some GUCs are unavoidable - standard_conforming_strings, for example probably still was a good idea, since the alternative would have been to stick with the historical, non-standard behaviour forever.
But in this case, my feeling is that the trouble such a GUC may cause out-weights the potential benefits. I'm all for having a directive like #consistent_into (though I feel that the name could convey the meaning better). If we *really* think that this ought to be the default from 9.4 onward, then we should
*) Change it to always complain, except if the function explictly specifies "#consistent_into on" or whatever.
*) Have pg_dump add that to all plpgsql functions if the server version is < 9.4 or whatever major release this ends up in
I disagree - automatic code injection can is strange. Is not problem inject code from simple DO statement, but I dislike append lines to source code without any specific user request.
Maybe this problem with GUC can be solved in 9.4. Some specific GUC can be ported with database.