Re: pg_dump and dependencies and --section ... it's a mess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump and dependencies and --section ... it's a mess
Date: 2012-06-24 15:19:02
Message-ID: 9756.1340551142@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-06-24 16:14:08 Re: random failing builds on spoonbill - backends not exiting...
Previous Message Alvaro Herrera 2012-06-24 03:01:56 Re: CREATE FOREGIN TABLE LACUNA