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

From Bruce Momjian
Subject Re: Controlling changes in plpgsql variable resolution
Date
Msg-id 200910201707.n9KH7NV16439@momjian.us
Whole thread Raw
In response to Re: Controlling changes in plpgsql variable resolution  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Controlling changes in plpgsql variable resolution
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Next
From: David Fetter
Date:
Subject: Going, going, GUCs!