On Thu, Nov 4, 2010 at 12:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Merlin Moncure <mmonc...@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. What 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
