Re: plpgsql.consistent_into - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsql.consistent_into
Date
Msg-id CAFj8pRCQ34VZXg-doeoDTx6FEo4qMNoERobu_KeN4KLhVexm0Q@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql.consistent_into  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-hackers



2014/1/13 Gavin Flower <GavinFlower@archidevsys.co.nz>
On 13/01/14 11:44, Florian Pflug wrote:
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

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

pgsql-hackers by date:

Previous
From: Oskari Saarenmaa
Date:
Subject: Re: pgcrypto: implement gen_random_uuid
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql.consistent_into