Re: pg_restore handles extended statistics inconsistently with statistics data

On Tue, Jun 16, 2026 at 11:07:22AM +0900, Michael Paquier wrote:
> 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.

And I am having second thoughts on this one. Take for example this
case:
CREATE SCHEMA s1;
CREATE SCHEMA s2;
CREATE TABLE s1.foo (id int);
INSERT INTO s1.foo SELECT generate_series(1,100);
ANALYZE s1.foo;
CREATE TABLE s2.bar (id int);
CREATE INDEX foo ON s2.bar(id);
INSERT INTO s2.bar SELECT generate_series(1,100);
ANALYZE s2.bar;

And then this:
pg_dump --statistics -Fc -f stats.dump mydb
pg_restore --statistics-only --index=foo -f stats_foo.sql stats.dump

On HEAD, we get relation and attribute we should not in stats_foo.sql,
getting also some data from the table s1.foo. With the patch
attached, that strengthens the name check based on the type of the
depending TOC entries, we only get the relation stats of s2.foo,
nothing about the table s1.foo. This feels too funky to write a test
for, wasting cycles compared to the existing coverage.

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.

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