On Oct 29, 2010, at 4:21 PM, "Kevin Grittner" <kevin.gritt...@wicourts.gov> wrote: > 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. > > I can't see back-patching it -- it's a behavior change. > > 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 could 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 be a self-serving argument based on wanting to tamp down the bug reports rather than a wisely considered policy decision... so I'm not sure I quite buy it. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
