On 9/3/21 5:56 AM, Justin Pryzby wrote:
On Wed, Sep 01, 2021 at 06:45:29PM +0200, Tomas Vondra wrote:
However while polishing the second patch, I realized we're allowing
statistics on expressions referencing system attributes. So this fails;
CREATE STATISTICS s ON ctid, x FROM t;
but this passes:
CREATE STATISTICS s ON (ctid::text), x FROM t;
IMO we should reject such expressions, just like we reject direct references
to system attributes - patch attached.
Right, same as indexes. +1
I've pushed this check, disallowing extended stats on expressions
referencing system attributes. This means we'll reject both ctid and
(ctid::text), just like for indexes.
Furthermore, I wonder if we should reject expressions without any Vars? This
works now:
CREATE STATISTICS s ON (11:text) FROM t;
but it seems rather silly / useless, so maybe we should reject it.
To my surprise, this is also allowed for indexes...
But (maybe this is what I was remembering) it's prohibited to have a constant
expression as a partition key.
Expressions without a var seem like a case where the user did something
deliberately silly, and dis-similar from the case of making a stats expression
on a simple column - that seemed like it could be a legitimate
mistake/confusion (it's not unreasonable to write an extra parenthesis, but
it's strange if that causes it to behave differently).
I think it's not worth too much effort to prohibit this: if they're determined,
they can still write an expresion with a var which is constant. I'm not going
to say it's worth zero effort, though.
I've decided not to push this. The statistics objects on expressions not
referencing any variables seem useless, but maybe not entirely - we
allow volatile expressions, like
CREATE STATISTICS s ON (random()) FROM t;
which I suppose might be useful. And we reject similar cases (except for
the volatility, of course) for indexes too.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
