Re: Function scan FDW pushdown
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Cc: solaimurugan vellaipandiyan <drsolaimurugan.v@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>, g.kashkin@postgrespro.ru, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-19T18:21:45Z
Lists: pgsql-hackers
Attachments
- v8-0001-postgres_fdw-push-down-FUNCTION-RTE-into-foreign-.patch (application/octet-stream)
Good evening!
On Tue, May 19, 2026 at 6:25 PM Alexander Pyhalov
<a.pyhalov@postgrespro.ru> wrote:
>
> Found one more issue in whole row var deparsing. It can appear on a
> nullable outer side, and we should use the same logic as when deparsing
> table column reference. Otherwise we get records from nulls instead of
> nulls (for example, "(NULL, NULL)" instead of NULL).
Good catch, accepted.
> Also I wonder if it is possible for get_tupdesc_for_join_scan_tuples()
> to get NULL rtfuncdata when it looks at RTE_FUNCTION RTE here:
>
> 1759 else if (rte->rtekind == RTE_FUNCTION && rtfuncdata
> != NIL)
> 1760 {
> 1761 /*
> 1762 * A whole-row Var points at a FUNCTION RTE
> absorbed into the
> 1763 * foreign join. Synthesize an anonymous
> composite TupleDesc from
> 1764 * the per-function return-type metadata we
> saved at plan time;
> 1765 * the deparser emits these as
> ROW(f<rti>.c1, f<rti>.c2, ...).
> 1766 */
> 1767 List *funcdata;
> 1768 TupleDesc rte_tupdesc;
> 1769 int num_funcs;
> 1770 int attnum;
> 1771 ListCell *lc1,
>
> ?
I don't see how that's possible. I think it would be safer to just
assert rtfuncdata/funcdata are not NULL. Revised patch is attached.
------
Regards,
Alexander Korotkov
Supabase