2014/1/12 Florian Pflug <f...@phlo.org> > On Jan12, 2014, at 22:37 , Pavel Stehule <pavel.steh...@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. Pavel > > That's all just my opinion of course. > > best regards, > Florian Pflug > >
