Re: Controlling changes in plpgsql variable resolution

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Controlling changes in plpgsql variable resolution
Дата
Msg-id 200910201707.n9KH7NV16439@momjian.us
обсуждение исходный текст
Ответ на Re: Controlling changes in plpgsql variable resolution  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Controlling changes in plpgsql variable resolution
Список pgsql-hackers
Pavel Stehule wrote:
> 2009/10/20 Tom Lane <tgl@sss.pgh.pa.us>:
> > Merlin Moncure <mmoncure@gmail.com> writes:
> >> How about warning for release before making the big switch? ?The text
> >> cast change, while ultimately good, maybe could have been stretched
> >> out for a release or two...it was painful. ?I do though absolutely
> >> think that it was good in the end to not support a compatibility
> >> option in core.
> >
> > As long as we provide a backwards-compatible setting, I don't believe
> > this change will be a huge deal. ?The problem with the implicit-casts
> > business was that there was no reasonable way to provide a control
> > switch --- the catalog entries were either there or not :-(. ?So far
> > as I can tell at the moment, there won't be any large technical cost
> > to providing a backwards-compatible option for this plpgsql change.
> 
> I don't thing, so drop some implicit-casts was huge problem. Somebody
> could to use Peter's patch, that recreate missing casts.

True, but we should have had those compatibility pathes (Peter's patch)
ready before we released, and advertised them in the release notes.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Следующее
От: David Fetter
Дата:
Сообщение: Going, going, GUCs!