> After chewing on this for awhile, I'm starting to come to the conclusion that we'd be best off to throw an error for SRF-inside-CASE (or COALESCE). Mark is correct that the simplest case of
> SELECT x, CASE WHEN y THEN generate_series(1,z) ELSE 5 END > FROM table_with_columns_x_and_y_and_z; > behaves just intuitively enough that people might be using it. The new implementation method cannot reasonably duplicate the old semantics for that, which means that if we let it stand as-is we will be > silently breaking queries, even if we fix up some of the weirder corner cases like what happens when the CASE can be const-simplified. So I think we'd be better off to make this throw an error, and force any > affected users to rewrite in a way that will work in both v10 and older releases. > As to *how* to throw an error, I think it should be possible to teach parse analysis to detect such cases, with something like the ParseExprKind mechanism that could be checked to see if we're inside a > subexpression that restricts what's allowed. There are some other checks like no-nested-aggregates that perhaps could be folded in as well. Checking at parse analysis ought to be sufficient because > rule rewriting could not introduce such a case where it wasn't before, and planner subquery flattening won't introduce one either because we don't flatten subqueries with SRFs in their tlists. > If people are on board with throwing an error, I'll go see about writing a patch. > regards, tom lane +1 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. Thanks, Regina -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
