| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, michael(at)paquier(dot)xyz |
| Subject: | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump |
| Date: | 2026-03-16 20:15:14 |
| Message-ID: | abhk0oLSA7lQ62jJ@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 16, 2026 at 04:04:23PM -0400, Corey Huinker wrote:
>> I left the expr_attnum stuff out. It seems to make this patch quite large
>> and complicated, we don't plan to use it for the pg_dump patch, and I'm not
>> sure about showing users a "synthetic attnum" that seems to have no other
>> point of reference. Would this information be useful in pg_dump somewhere?
>> I'm curious to hear more about the intent.
>
> expr_attnum was something that Michael Paquier had lamented that the view
> didn't have. There is obviously no present need for it, as pg_dump isn't
> being modified for extended stats at all.
Okay. I think I'll continue to leave this one out for now.
>> I didn't see much value in adding attnum here given the size of the changes
>> to the expected output it produces.
>
> Same reasons for putting that in - people had lamented that we couldn't
> order the dump by attnum, and ordering by attname feels weird somehow.
> Again, we don't presently need it.
This note was about adding attnum to the pg_stats_stable view in the test.
I don't have any problem with adding it to pg_stats.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-03-16 20:51:09 | Re: pg_plan_advice |
| Previous Message | Corey Huinker | 2026-03-16 20:04:23 | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump |