Re: pg_restore handles extended statistics inconsistently with statistics data

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: pg_restore handles extended statistics inconsistently with statistics data
Date: 2026-06-15 19:25:39
Message-ID: CADkLM=f54QXpDOBMC19tcq47hOyGhp_hKrBkBqoVKc9aTXdQxA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> We cannot just add a strcmp(te->desc, "STATISTICS DATA") == 0 check to the
> "else if (strcmp(te->desc, "INDEX") == 0)" branch, because STATISTICS DATA
> would already have matched the earlier table branch. So in v4, I pulled
> STATISTICS DATA into its own branch before the table and index branches.
>
>
v4 is looking good, though I'm a bit frustrated that that `pg_dump -s -t
s1.t` will include the index creations but not not the extended stats
objects. Feels like an oversight.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-06-15 19:28:17 [oauth] Increased CPU usage during device flow with libcurl 8.20.0
Previous Message Álvaro Herrera 2026-06-15 18:44:30 Re: [PATCH] REPLICA IDENTITY USING INDEX accepts column with invalid NOT NULL