Fix array-element quoting in postgres_fdw import statistics - Mailing list pgsql-hackers

From SATYANARAYANA NARLAPURAM
Subject Fix array-element quoting in postgres_fdw import statistics
Date
Msg-id CAHg+QDc9=WtYi=JW6QUL6ASOJc6PcGPTuxoMkhnkQ7oi7j5atg@mail.gmail.com
Whole thread
Responses Re: Fix array-element quoting in postgres_fdw import statistics
List pgsql-hackers
Hi,

build_remattrmap() used quote_identifier() to format column names
for a text[] array literal passed to the remote pg_stats query.
quote_identifier() applies SQL identifier quoting, which doubles
double-quote characters but does not escape backslashes.  However,
inside a PostgreSQL array literal, backslash is an escape character.

Column names containing backslashes (e.g. "a\b") were silently
mangled by the array parser—"a\b" became "ab"—causing the
WHERE attname = ANY('{...}') filter to miss those columns.  The
statistics import would then fail with a WARNING about missing
attribute statistics. This is a very corner cases because usually
backslash is not included in the column names. Anyways attached
a draft patch. Please take a look and let me know what you think.

-- Setup
CREATE TABLE bs_test (id int PRIMARY KEY, "a\b" int, normal_col text);
INSERT INTO bs_test SELECT g, g, 'val' FROM generate_series(1,1000) g;
ANALYZE bs_test;

CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host '127.0.0.1', port '5432', dbname 'testdb', restore_stats 'true');
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback OPTIONS (user 'postgres');

CREATE FOREIGN TABLE fbs_test (id int, "a\b" int, normal_col text)
    SERVER loopback OPTIONS (schema_name 'public', table_name 'bs_test');

ANALYZE fbs_test;
-- WARNING: could not import statistics for foreign table "public.fbs_test"
--- no attribute statistics found for column "a\b"  of remote table "public.bs_test"


Thanks,
Satya
Attachment

pgsql-hackers by date:

Previous
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Bug: trailing comma syntax error in postgres_fdw fetch_attstats()
Next
From: Alexander Lakhin
Date:
Subject: Re: Non-compliant SASLprep implementation for ASCII characters