Re: Controlling changes in plpgsql variable resolution - Mailing list pgsql-hackers

Pavel Stehule <pavel.stehule@gmail.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.)

(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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: u235sentinel
Date:
Subject: Re: postgres 8.3.8 and Solaris 10_x86 64 bit problems?
Next
From: Robert Haas
Date:
Subject: Re: Controlling changes in plpgsql variable resolution