On Tue, Apr 21, 2026 at 7:55 PM Etsuro Fujita <[email protected]> wrote: > On Sun, Apr 12, 2026 at 3:46 PM Etsuro Fujita <[email protected]> wrote: > > On Sun, Apr 12, 2026 at 12:13 PM SATYANARAYANA NARLAPURAM > > <[email protected]> wrote: > > > 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.
> I think your analysis is correct, but a simpler solution for this > issue is to use deparseStringLiteral() for column names, instead of > quote_identifier(), as proposed in [1]. For the record: this has been addressed using the patch in that thread (see commit 5107398e6d5e). Best regards, Etsuro Fujita
