On Fri, Oct 29, 2010 at 4:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> Robert Haas <robertmh...@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. 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. > >> 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? 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.
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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
