On 8/18/21 5:07 AM, Justin Pryzby wrote:
>> Patch 0001 fixes the "double parens" issue discussed elsewhere in this
>> thread, and patch 0002 tweaks CREATE STATISTICS to treat "(a)" as a simple
>> column reference.
>
>> From: Tomas Vondra <tomas.vondra@postgresql.org>
>> Date: Mon, 16 Aug 2021 17:19:33 +0200
>> Subject: [PATCH 2/2] fix: identify single-attribute references
>
>> diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
>> index a4ee54d516..be1f3a5175 100644
>> --- a/src/bin/pg_dump/t/002_pg_dump.pl
>> +++ b/src/bin/pg_dump/t/002_pg_dump.pl
>> @@ -2811,7 +2811,7 @@ my %tests = (
>> create_sql => 'CREATE STATISTICS dump_test.test_ext_stats_expr
>> ON (2 * col1) FROM dump_test.test_fifth_table',
>> regexp => qr/^
>> - \QCREATE STATISTICS dump_test.test_ext_stats_expr ON ((2 * col1)) FROM dump_test.test_fifth_table;\E
>> + \QCREATE STATISTICS dump_test.test_ext_stats_expr ON (2 * col1) FROM dump_test.test_fifth_table;\E
>
>
> This hunk should be in 0001, no ?
>
Yeah, I mixed that up a bit.
>> But I'm not sure 0002 is something we can do without catversion bump. What
>> if someone created such "bogus" statistics? It's mostly harmless, because
>> the statistics is useless anyway (AFAICS we'll just use the regular one we
>> have for the column), but if they do pg_dump, that'll fail because of this
>> new restriction.
>
> I think it's okay if it pg_dump throws an error, since the fix is as easy as
> dropping the stx object. (It wouldn't be okay if it silently misbehaved.)
>
> Andres concluded similarly with the reverted autovacuum patch:
> https://www.postgresql.org/message-id/20210817105022.e2t4rozkhqy2myhn@alap3.anarazel.de
>
> +RMT in case someone wants to argue otherwise.
>
I feel a bit uneasy about it, but if there's a precedent ...
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company