Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
| От | Nathan Bossart |
|---|---|
| Тема | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump |
| Дата | |
| Msg-id | abhk0oLSA7lQ62jJ@nathan обсуждение исходный текст |
| Ответ на | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump (Corey Huinker <corey.huinker@gmail.com>) |
| Ответы |
Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
|
| Список | 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
В списке pgsql-hackers по дате отправления: