> > > 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.
- pg_restore handles extended statistics inconsistently with... Chao Li
- Re: pg_restore handles extended statistics inconsiste... Michael Paquier
- Re: pg_restore handles extended statistics incons... Chao Li
- Re: pg_restore handles extended statistics in... Chao Li
- Re: pg_restore handles extended statistic... Michael Paquier
- Re: pg_restore handles extended stat... Chao Li
- Re: pg_restore handles extended ... Corey Huinker
- Re: pg_restore handles exten... Michael Paquier
- Re: pg_restore handles exten... Michael Paquier
- Re: pg_restore handles exten... Michael Paquier
- Re: pg_restore handles exten... Corey Huinker
- Re: pg_restore handles exten... Chao Li
- Re: pg_restore handles exten... Michael Paquier
- Re: pg_restore handles exten... Chao Li
- Re: pg_restore handles exten... Corey Huinker
