On Fri, Oct 29, 2010 at 4:12 PM, 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.
>
>>> Well, then let's do that. =A0It'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.
>
>> 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.
>
> 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? =A0We'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.
Trying to understand real world cases that this would break...would
the following now fail w/o explicit cast?
create type x as (a int, b int);
select f((1,2));
merlin