Re: plpgsql.consistent_into

2014/1/13 Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>

> On 13/01/14 11:44, Florian Pflug wrote:
>
>> On Jan12, 2014, at 22:37 , Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
>