On Mon, Aug 16, 2021 at 05:41:57PM +0200, Tomas Vondra wrote: > > This still seems odd: > > > > postgres=# CREATE STATISTICS asf ON i FROM t; > > ERROR: extended statistics require at least 2 columns > > postgres=# CREATE STATISTICS asf ON (i) FROM t; > > CREATE STATISTICS > > > > It seems wrong that the command works with added parens, but builds > > expression > > stats on a simple column (which is redundant with what analyze does without > > extended stats). > > Well, yeah. But I think this is a behavior that was discussed somewhere in > this thread, and the agreement was that it's not worth the complexity, as > this comment explains > > * XXX We do only the bare minimum to separate simple attribute and > * complex expressions - for example "(a)" will be treated as a complex > * expression. No matter how elaborate the check is, there'll always be > * a way around it, if the user is determined (consider e.g. "(a+0)"), > * so it's not worth protecting against it. > > 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.
0002 refuses to create expressional stats on a simple column reference like (a), which I think is helps to avoid a user accidentally creating useless ext stats objects (which are redundant with the table's column stats). 0002 does not attempt to refuse cases like (a+0), which I think is fine: we don't try to reject useless cases if someone insists on it. See 240971675, 701fd0bbc. So I am +1 to apply both patches. I added this as an Opened Item for increased visibility. -- Justin
