From: Justin Pryzby <pryzby@telsasoft.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: pgsql-hackers@postgresql.org, Michael Paquier <michael@paquier.xyz>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: PoC/WIP: Extended statistics on expressions
Date: Tue, 17 Aug 2021 22:07:54 -0500
Message-ID: <20210818030754.GP10479@telsasoft.com> (raw)
In-Reply-To: <a2be7e05-e6b7-1467-d15a-49011e45a4b8@enterprisedb.com>
References: <3fbbd68b-0b52-cb5a-d468-7e7280c33e6c@enterprisedb.com>
<4654037b-8df8-77fb-2981-67be93aebdf1@enterprisedb.com>
<20201123022604.GD24052@telsasoft.com>
<e5beb5d5-28b4-7aad-3a16-9a6abf57f897@enterprisedb.com>
<6455e0ad-2a2e-bdb0-e1f8-fd4983d1c8aa@enterprisedb.com>
<087086de-1384-8374-4efc-2e7915071d5c@enterprisedb.com>
<CAEZATCU9uPo7JYdx4k0-ufXXZH8t7itodibUwCva+s+AvAKcnw@mail.gmail.com>
<b2995773-c9a1-5d3b-fc90-4f3ab189be11@enterprisedb.com>
<20210816013255.GS10479@telsasoft.com>
<a2be7e05-e6b7-1467-d15a-49011e45a4b8@enterprisedb.com>
> 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 ?
> 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.
--
Justin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, tomas.vondra@enterprisedb.com, dean.a.rasheed@gmail.com, michael@paquier.xyz, pg@bowt.ie, andrew@dunslane.net
Subject: Re: PoC/WIP: Extended statistics on expressions
In-Reply-To: <20210818030754.GP10479@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox