"Regina Obe" <l...@pcorp.us> writes: > I'm not a fan of either solution, but I think what Tom proposes of throwing > an error sounds like least invasive and confusing.
> I'd much prefer an error thrown than silent behavior change. Given that we > ran into this in 3 places in PostGIS code, I'm not convinced the issue is > all that rare. > Make sure to point out the breaking change in the release notes though and > syntax to remedy it. As far as that goes, the best fix I could think of after a few minutes is to integrate your conditional logic into a custom set-returning function. For example, select x, case when y > 0 then generate_series(1, z) else 5 end from tt; could become create function mysrf(cond bool, start int, fin int, els int) returns setof int as $$ begin if cond then return query select generate_series(start, fin); else return query select els; end if; end$$ language plpgsql; select x, mysrf(y > 0, 1, z, 5) from tt; (adjust the amount of parameterization to taste, of course) Now, the fact that a fairly mechanical conversion like this is possible suggests that we *could* solve the problem if we had to, at least for simple cases like this one. But it'd be a lot of work, not least because we'd presumably not want core-defined syntax to depend on an extension like plpgsql --- and I don't see a way to do this with straight SQL functions. So my feeling is that we should not expend that effort. If it turns out that a lot more people are affected than I currently think will be the case, maybe we'll have to revisit that choice. But this line of thinking does strengthen my feeling that throwing an error is the right thing to do for the moment. If we allow v10 to accept such cases but do something different from what we used to, that will greatly complicate any future attempt to try to restore the old behavior. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers