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

From Michael Paquier
Subject Re: pg_restore handles extended statistics inconsistently with statistics data
Date
Msg-id ajCv2umDUeJiHtoz@paquier.xyz
Whole thread
In response to Re: pg_restore handles extended statistics inconsistently with statistics data  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_restore handles extended statistics inconsistently with statistics data
List pgsql-hackers
On Tue, Jun 16, 2026 at 07:15:51AM +0900, Michael Paquier wrote:
> That's the behavior since v15.  Contrary to you, the behavior of
> specifying a table in pg_dump and pg_restore but not including a stats
> definition makes more sense here.  The reasoning is that a stats
> object may live on a different schema than the table it is defined on,
> so you cannot guarantee that its schema has been created if you only
> create a table on a schema.

Sharing the check for a STATISTICS DATA TOC entry on table and index
names was making me ticking a bit, as this is not entirely
collision-proof for the names, but it also looks like we do things the
same way with TABLE DATA and INDEX, so..  At the end, applied down to
v18 as suggested.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Ewan Young
Date:
Subject: Re: REPACK CONCURRENTLY fails on tables with generated columns
Next
From: Corey Huinker
Date:
Subject: Re: pg_restore handles extended statistics inconsistently with statistics data