From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Subject: | Re: Weird pg_dumpall bug? |
Date: | 2006-01-24 17:00:47 |
Message-ID: | 19897.1138122047@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Dienstag, 24. Januar 2006 15:44 schrieb Stephen Frost:
>> Have you got a suggestion on just how to fix it...? Debian's
>> pg_upgradecluster bails out with an error when it discovers this
>> situation but I don't think it'd be sensible for pg_dump to do that...
> Why not? If the backup cannot be made in a way such that the
> semantics of the restored database are the same, it shouldn't do it.
If you take a hard line on that position, then it's not necessary for
pg_dump to support cross-version operation at all, because no major
PG release is ever 100.0% compatible with the previous one.
What is actually required of pg_dump is that it produce the closest
approximation it can get to the old behavior within the context of the
new version's semantics. I can easily cite half a dozen examples of
cases where we've applied this logic in previous versions. I do not
see a reason to treat this case differently. The difference between
a single role acting as both user and group and the prior behavior of
separate objects is certainly well within the "fuzz factor" that we've
allowed pg_dump to have in the past.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-24 18:23:17 | Cleaning up the INET/CIDR mess |
Previous Message | Alexey Slynko | 2006-01-24 16:58:11 | TODO item: locale per database patch (new iteration) |