Re: pg_restore handles extended statistics inconsistently with statistics data - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: pg_restore handles extended statistics inconsistently with statistics data
Date
Msg-id CADkLM=duaKbs5bjMJ4YUGkiEOjAjKMeiU_pC-_ciC6ppGqH+UA@mail.gmail.com
Whole thread
In response to Re: pg_restore handles extended statistics inconsistently with statistics data  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
pg_restore --index is as old as e8f69be054e9, so it's not like we
could just remove it, but I'd say that with the schema-level restore
this would be tempting. 

That temptation tells me that there is no appetite for a similar flag for named extended stats objects, which makes me wonder how somebody would get all of the extended stats objects and the pg_restore_extended_stats() calls for a given table, aside from manually filtering the output of a --no-data --statistics dump. It's not a very common use case right now, but I suspect the cases for it will increase in the future.
 

Anyway, let's improve this situation with the attached, for HEAD and
v18.

+1 to this. 

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Next
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication