2014/1/13 Gavin Flower <gavinflo...@archidevsys.co.nz> > On 13/01/14 11:44, Florian Pflug wrote: > >> 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 >> >> That's all just my opinion of course. >> >> best regards, >> Florian Pflug >> >> >> >> Possibly there should be a warning put out, whenever someone uses some > behaviour that requires a GUC set to a non-default value? >
It is a good idea. I though about it. A worry about GUC are legitimate, but we are most static and sometimes we try to design bigger creatures, than we try to solve. I am thinking so dump can contain a serialized GUC values, and can raises warnings when GUC are different (not only different from default). Similar problems are with different FROM_COLAPS_LIMIT, JOIN_COLAPS_LIMIT, WORK_MEM, ... Regards Pavel > > > Cheers, > Gavin >
