On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Merlin Moncure <mmoncure@gmail.com> wrote:
>>> 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));
>
>> It already does:
>
> I think Merlin probably meant to write "select x((1,2))", but that
> doesn't work out-of-the-box either. =A0What would be affected is
> something like
Actually I didn't -- I left out that there was a function f taking x.
I misunderstood your assertion above: "The notation t(x) will be taken
to mean x::t if there's no function t() taking x's type, but there is
a cast from x's type to t".
I thought you meant that it would no longer implicitly cast where it
used to for record types, rather than the expression rewrite it was
doing (it just clicked). Anyways, no objection to the change, or even
the backpatch if you'd like to do that. FWIW.
If we ever have an IOCCCish contest for postgresql variant of SQL,
there are some real gems in this thread :-).
merlin
