Re: Controlling changes in plpgsql variable resolution

On Mon, Oct 19, 2009 at 1:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> ambiguous identifiers is probably the top reason of some plpgsql's
>> mysterious errors. More times I found wrong code - sometime really
>> important (some security checks). I never found good code with
>> ambiguous identifiers - so for me, exception is good. But - there will
>> be lot of working applications that contains this hidden bug - and
>> works "well". So it could be a problem. GUC should be a solution.
>
> So the conclusions so far are:
>
> (a) Nobody but me is afraid of the consequences of treating this as
> a GUC.  (I still think you're all wrong, but so be it.)

I'm afraid of it, I'm just not sure I have a better idea. It wouldn't
bother me a bit if we made the only available behavior "throw an
error", but I'm afraid it will bother someone else.

Is there a chance we could make this a GUC, but only allow it to be
changed at the function level, with no way to override the server
default? It seems to me that the chances of blowing up the world
would be a lot lower that way, though possibly still not low enough.

> (b) Everybody agrees that a "throw error" setting would be helpful.
>
> I am not sure there's any consensus on what the default setting should
> be, though.  Can we get away with making the default be "throw error"?
> What are the probabilities that the OpenACSes of the world will just
> set the value to "backward compatible" instead of touching their code?
> Do we need/want a hack in pg_dump to attach a SET to functions dumped
> from old DBs?

I've already commented on most of these (recap: yes, very high, yes)
so I'll refrain from beating a dead horse.

...Robert