On Oct 29, 2010, at 4:21 PM, "Kevin Grittner" <Kevin.Grittner@wicourts.gov>=
wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>>> Robert Haas <robertmhaas@gmail.com> wrote:
>>>>> I think if I had to pick a proposal, I'd say we should disable
>>>>> #2 for the specific case of casting a composite type to
>>>>> something else.
>>=20
>>>> Well, then let's do that. It's not the exact fix I'd pick, but
>>>> it's clearly better than nothing, so I'm willing to sign on to
>>>> it as a compromise position.
>>=20
>>> So, I'd rather scrap #2 entirely; but if that really would break
>>> much working code, +1 for ignoring it when it would cast a
>>> composite to something else.
>>=20
>> Well, assuming for the sake of argument that we have consensus on
>> fixing it like that, is this something we should just do in HEAD,
>> or should we back-patch into 8.4 and 9.0? We'll be hearing about
>> it nigh indefinitely if we don't, but on the other hand this isn't
>> the kind of thing we like to change in released branches.
>=20
> I can't see back-patching it -- it's a behavior change.
>=20
> On the bright side, in five years after the release where it's
> removed, it will be out of support. Problem reports caused by it
> should be tapering off before that....
Yeah, I think we're going to have to live with it, at least for 8.4. One c=
ould make an argument that 9.0 is new enough we could get away with a small=
behavior change to avoid a large amount of user confusion. But that may b=
e a self-serving argument based on wanting to tamp down the bug reports rat=
her than a wisely considered policy decision... so I'm not sure I quite bu=
y it.
...Robert
