Re: Function scan FDW pushdown - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Function scan FDW pushdown
Date
Msg-id CAPpHfduLKwM=Jj-0q+vWiwNOLYfhJQFs+c-YPF8=voPD1M_trQ@mail.gmail.com
Whole thread
In response to Re: Function scan FDW pushdown  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Alexander Pyhalov
Date:
Subject: Re: Function scan FDW pushdown
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Fix REPACK decoding worker not cleaned up on FATAL exit