Обсуждение: [PATCH] Fix column name escaping in postgres_fdw stats import

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

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()
isa 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

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