On 2/21/17 4:25 PM, Peter Eisentraut wrote:
> On 2/21/17 14:58, Jim Nasby wrote:
>> AFAICT in older versions only object types that absolutely had to wait
>> for DO_POST_DATA_BOUNDARY would do so. More recently though, objects are
>> being added after that (presumably because it's easier than renumbering
>> everything in dbObjectTypePriority).
>
> Is there any specific assignment that you have concerns about?
Originally, no, but reviewing the list again I'm kindof wondering about
DO_DEFAULT_ACL, especially since the acl code in pg_dump looks at
defaults as part of what removes the need to explicitly dump
permissions. I'm also wondering if DO_POLICY could potentially affect
matviews?
Actually, I think matviews really need to be the absolute last thing.
What if you had a matview that referenced publications or subscriptions?
I'm guessing that would be broken right now.
>> Is this change a good or bad idea? Should there be an official guide for
>> where new things go?
>
> The comment above dbObjectTypePriority explains it, doesn't it?
Not really; it just makes reference to needing to be in-sync with
pg_dump.c. My concern is that clearly people went to lengths in the past
to put everything possible before DO_PRE_DATA_BOUNDARY (ie, text search
and FDW) but most recently added stuff has gone after
DO_POST_DATA_BOUNDARY, even though there's no reason it couldn't be
pre-data. That's certainly a change, and I suspect it's not intentional
(other than it's obviously less work to stick stuff at the end, but that
could be fixed by having an array of the actual enum values and just
having pg_dump sort that when it starts).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)