Re: Several issues with postgres_fdw stats import

Hi all,

On 23/09/26 20:58, Etsuro Fujita wrote:
> On Thu, Sep 24, 2026 at 12:11 AM Nathan Bossart
> <nathandbossart(at)gmail(dot)com> wrote:
>> Can the open item for this one be marked resolved?
>
> Yes, I think so; I will push two remaining patches by this weekend at
> the latest.
>

While testing the postgres_fdw statistics import feature, I also ran
into issue (1), "User-defined functions may be executed with unexpected
privileges".

I've tested Noah's patch that Etsuro shared, and it looks good to me. It
fixes both the domain-function case and the data disclosure case in all
the scenarios I tried.

Since the patch doesn't include regression tests, I'm attaching a
patch with two tests added:

- The first is based on Noah's example: a superuser runs ANALYZE on a
foreign table owned by a non-superuser that has no user mapping. It
now fails with "user mapping not found" instead of importing
statistics the owner can't read.

- The second covers the case Fujii described: a domain CHECK constraint
on a foreign table column calls a function that reports current_user
and search_path. It now runs as the table owner with search_path set
to "pg_catalog, pg_temp".

I also added a paragraph to the ImportForeignStatistics section on
fdwhandler.sgml saying that the callback runs as the foreign table's
owner in a security-restricted operation, so FDWs should use the owner's
user mapping. This is now part of the callback's contract, and it
differs from AnalyzeForeignTable, which is still called as the user
running ANALYZE, so I think it's worth documenting for FDW authors.

Noah's code changes are unchanged; the attached patch adds only the
tests, the docs and a commit message.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com