Re: Add expressions to pg_restore_extended_stats() - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Add expressions to pg_restore_extended_stats()
Date
Msg-id CADkLM=dDRm_s1WiqGehOq_R_Q+HOK-k9i7DX5w4wpU2yJo7qAg@mail.gmail.com
Whole thread
In response to Re: Add expressions to pg_restore_extended_stats()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add expressions to pg_restore_extended_stats()
List pgsql-hackers
By the way, the test you have proposed in [1] to copy the expression
stats from an origin to a target and check the differences was super
nice.  Could you add that back, with 'exprs' set as a jsonb blob?
This was posted in 0003, but got cut due to the initial integration of
the feature without expressions.

+1 

 
I have put my hands on the patch, and fixed all these issues, adding
tests to cover the holes I have spotted, and addressed a lot of
stylistic things.  I did not take the time to add the diff test,
though when the expressions are cloned.  Could you?

+1
 
The cases of STATISTIC_KIND_RANGE_LENGTH_HISTOGRAM and
STATISTIC_KIND_BOUNDS_HISTOGRAM are a bit sad.  How about exposing
them into pg_stats_ext_exprs as a first patch, then extend the
expression restore function to be able to work on them?  Modifying the
view would be an entirely independent thing.  Please note that I do
not mind skipping these two cases for now, the proposed patch is
already doing a lot.  Still if we are able to close entirely the loop
for this release that would be nice.  Anyway, let's keep this stuff as
separate patches on top of this v8 and future reviewed versions.

I was thinking of doing exactly that, with a lot of language around how these extra patches don't need to make it into v19. But having said that, they'll probably be pretty small.
 

pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Optimize IS DISTINCT FROM with non-nullable inputs
Next
From: jian he
Date:
Subject: Re: CREATE TABLE LIKE INCLUDING TRIGGERS