Re: Controlling changes in plpgsql variable resolution
От | Tom Lane |
---|---|
Тема | Re: Controlling changes in plpgsql variable resolution |
Дата | |
Msg-id | 13124.1256158971@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Controlling changes in plpgsql variable resolution (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Controlling changes in plpgsql variable resolution
Re: Controlling changes in plpgsql variable resolution |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > I actually think that we should not have a GUC for this at all. We > should have a compiled-in default, and it should be error. If you > want some other behavior, decorate your functions with #option. We've agreed that the factory default should be "error", but I don't think we can go much further than that in the direction of breaking peoples' code. We need to provide a backwards-compatible option, IMHO, so that this isn't seen as a roadblock to updating to 8.5. (You can argue all you want about whether it really is one, but it'll be seen as one.) And the Oracle-compatible option will be attractive to people coming in from that side. Reviewing megabytes of pl/sql code for this kind of gotcha is not fun, and the "error" default would only help a bit. One advantage of making the GUC be SUSET is that those who want to take a paranoid approach here have an easy answer: don't allow it to be changed from "error". We are allowed to assume that those who do change it are responsible adults. regards, tom lane
В списке pgsql-hackers по дате отправления: