Andrew Dunstan <and...@dunslane.net> writes:
> On 06/22/2012 04:43 PM, Tom Lane wrote:
>> A possible objection to it is that there are now three different ways in
>> which the pg_dump code knows which DO_XXX object types go in which dump
>> section: the new addBoundaryDependencies() function knows this, the
>> SECTION_xxx arguments to ArchiveEntry calls know it, and the sort
>> ordering constants in pg_dump_sort.c have to agree too. My original
>> idea was to add an explicit section field to DumpableObject to reduce
>> the number of places that know this, but that would increase pg_dump's
>> memory consumption still more, and yet still not give us a single point
>> of knowledge. Has anybody got a better idea?
> Not off hand.
I still don't have a great idea for eliminating the duplicativeness,
but it occurred to me that we could add a bit of code to check that the
finished TOC list is in correct section order. This should catch most
cases where one value is out of sync with the others, and it seems like
a good idea in any case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
