Re: Controlling changes in plpgsql variable resolution

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Controlling changes in plpgsql variable resolution
Дата
Msg-id 8312.1255974628@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Controlling changes in plpgsql variable resolution  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Controlling changes in plpgsql variable resolution  (Robert Haas <robertmhaas@gmail.com>)
Re: Controlling changes in plpgsql variable resolution  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Controlling changes in plpgsql variable resolution  (Andrew Dunstan <andrew@dunslane.net>)
Could postgres be much cleaner if a future release skipped backward compatibility?  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Список 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 по дате отправления:

Предыдущее
От: u235sentinel
Дата:
Сообщение: Re: postgres 8.3.8 and Solaris 10_x86 64 bit problems?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution