From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plpgsql.consistent_into |
Date: | 2014-01-13 05:06:42 |
Message-ID: | CAFj8pRDB_WUpWkG85eDQ1UEFFUuEOi7JhBLdpu2TEQT=j4DfAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014/1/12 Florian Pflug <fgp(at)phlo(dot)org>
> 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
>
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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Steeve Lennmark | 2014-01-13 05:13:07 | Re: [PATCH] Relocation of tablespaces in pg_basebackup |
Previous Message | Adrian Klaver | 2014-01-13 04:41:27 | Re: [GENERAL] pg_upgrade & tablespaces |