Re: PoC/WIP: Extended statistics on expressions

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