[PATCH] Fix column name escaping in postgres_fdw stats import

On 4/21/26 4:43 AM, Ayush Tiwari wrote:

Hi hackers,

The new statistics import feature in postgres_fdw (commit 28972b6fc3d)
builds a remote query to fetch pg_stats rows, filtering by column name
with:

  AND attname = ANY('{col1, col2}'::text[])

The column names are formatted with quote_identifier(), which only
escapes double quotes.  But since the list is embedded inside a
single-quoted string literal, any single quote in a column name
breaks the literal and produces a syntax error on the remote server.

Reproduction:

  CREATE TABLE t ("col'quote" int, c2 int);
  INSERT INTO t SELECT g, g FROM generate_series(1,100) g;
  ANALYZE t;

  CREATE FOREIGN TABLE ft ("col'quote" int, c2 int)
    SERVER loopback OPTIONS (table_name 't', restore_stats 'true');

  ANALYZE ft;
  -- ERROR:  syntax error at or near "quote"
  -- CONTEXT:  remote SQL command: ... attname = ANY('{...
"col'quote"}'::text[])

The attached patch switches to an ARRAY[] constructor with each
element escaped by deparseStringLiteral(), matching how schemaname
and tablename are already handled in the same function.

Thoughts?

It should also address the issue that was raised in [1].

[1] PostgreSQL: Fix array-element quoting in postgres_fdw import
statistics
</messages/by-id/CAHg+QDc9=WtYi=JW6QUL6ASOJc6PcGPTuxoMkhnkQ7oi7j5atg@mail.gmail.com&gt;

Regards,
Ayush

I think the fix makes sense to me. Here, the column names are emitted as
string content, thus deparseStringLiteral() is a better fit. A small
comment on the test:

+ANALYZE VERBOSE simport_ft_quote;         -- should work, not syntax error

VERBOSE seems not needed.
Regards, Alex Guo

On Tue, Apr 21, 2026 at 3:12 PM Alex Guo <guo.alex.hengchen@gmail.com> wrote:

On 4/21/26 4:43 AM, Ayush Tiwari wrote:
The new statistics import feature in postgres_fdw (commit 28972b6fc3d)
builds a remote query to fetch pg_stats rows, filtering by column name
with:

AND attname = ANY('{col1, col2}'::text[])

The column names are formatted with quote_identifier(), which only
escapes double quotes. But since the list is embedded inside a
single-quoted string literal, any single quote in a column name
breaks the literal and produces a syntax error on the remote server.

The attached patch switches to an ARRAY[] constructor with each
element escaped by deparseStringLiteral(), matching how schemaname
and tablename are already handled in the same function.

Thanks for the report and patch!

It should also address the issue that was raised in [1].

The root cause of this is the same as [1], so I think you should reply
to the thread, rather than creating a new thread.

I think the fix makes sense to me. Here, the column names are emitted as string content, thus deparseStringLiteral() is a better fit.

+1

A small comment on the test:

+ANALYZE VERBOSE simport_ft_quote; -- should work, not syntax error

VERBOSE seems not needed.

I think the option is needed; otherwise we cannot check that stats
import was really done in the test.

Best regards,
Etsuro Fujita

Hi,

Thanks for the review!

On Tue, 21 Apr 2026 at 17:00, Etsuro Fujita <etsuro.fujita@gmail.com> wrote:

On Tue, Apr 21, 2026 at 3:12 PM Alex Guo <guo.alex.hengchen@gmail.com>
wrote:

On 4/21/26 4:43 AM, Ayush Tiwari wrote:
The new statistics import feature in postgres_fdw (commit 28972b6fc3d)
builds a remote query to fetch pg_stats rows, filtering by column name
with:

AND attname = ANY('{col1, col2}'::text[])

The column names are formatted with quote_identifier(), which only
escapes double quotes. But since the list is embedded inside a
single-quoted string literal, any single quote in a column name
breaks the literal and produces a syntax error on the remote server.

The attached patch switches to an ARRAY[] constructor with each
element escaped by deparseStringLiteral(), matching how schemaname
and tablename are already handled in the same function.

Thanks for the report and patch!

It should also address the issue that was raised in [1].

The root cause of this is the same as [1], so I think you should reply
to the thread, rather than creating a new thread.

I faced the issue with the quoting scenario and was unaware of [1] then,
and that patch did not solve the issue regarding the quotes, which is
why I started this. Should I move this there? I've registered it in
commitfest: Fix column name escaping in postgres_fdw stats import
<https://commitfest.postgresql.org/patch/6695/&gt;

I think the fix makes sense to me. Here, the column names are emitted as

string content, thus deparseStringLiteral() is a better fit.

+1

A small comment on the test:

+ANALYZE VERBOSE simport_ft_quote; -- should work, not syntax

error

VERBOSE seems not needed.

I think the option is needed; otherwise we cannot check that stats
import was really done in the test.

Yeah, that was the intention.

Regards,
Ayush

On Tue, Apr 21, 2026 at 8:40 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:

On Tue, 21 Apr 2026 at 17:00, Etsuro Fujita <etsuro.fujita@gmail.com> wrote:

On 4/21/26 4:43 AM, Ayush Tiwari wrote:

It should also address the issue that was raised in [1].

The root cause of this is the same as [1], so I think you should reply
to the thread, rather than creating a new thread.

I faced the issue with the quoting scenario and was unaware of [1] then,
and that patch did not solve the issue regarding the quotes, which is
why I started this. Should I move this there?

No, you shouldn't, but I think it's usual to discuss (essentially) the
same problem in a single place.

Best regards,
Etsuro Fujita