| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Martijn van Oosterhout <kleptog(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17564: Planner bug in combination of generate_series(), unnest() and ORDER BY |
| Date: | 2022-08-03 14:09:12 |
| Message-ID: | 2967745.1659535752@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> - if (IS_SRF_CALL((Node *) em->em_expr))
> + if (expression_returns_set((Node *) em->em_expr))
Yeah. I think we need to go further: placed in optimizer.h as
it is, IS_SRF_CALL is just an invitation to writing broken code.
I think the calls in tlist.c are legit because that code is
precisely concerned with breaking down nests of SRFs; but
everywhere else, if you write IS_SRF_CALL you're doing it wrong.
We should take that macro out of the header altogether.
I kind of wonder whether IS_SRF_CALL is a good idea at all.
It'd be more maintainable to have an expression_returns_set_one_level,
or something like that, placed beside expression_returns_set.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2022-08-03 14:23:34 | BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY |
| Previous Message | Juan José Santamaría Flecha | 2022-08-03 11:13:09 | Re: BUG #17567: Unable to Set Max_Connection in Postgresql which has replicas |