Weird pg_dumpall bug?

* Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:

Hmmmm...actually. It's because I have a user called 'support' and a
group called 'support'.

Seems like it needs a fix...

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...

Thanks,

Stephen

On Tue, 2006-01-24 at 09:44 -0500, Stephen Frost wrote:

* Christopher Kings-Lynne (chriskl@familyhealth.com.au) wrote:

Hmmmm...actually. It's because I have a user called 'support' and a
group called 'support'.

Seems like it needs a fix...

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...

How about an option to map groups whose names conflict with user names
using a prefix mechanism?

e.g. --map-conflicting-groups=gr_

Then in Christopher's example his support group would become the role
gr_support.

Just a thought.

cheers

andrew

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

Hmmmm...actually. It's because I have a user called 'support' and a
group called 'support'.

This was discussed already. It's a corner case we didn't really think
about while designing roles. It's possible to support this: the group
and the user will now really be the same entity, ie a role that has both
its own login privileges and members. However pg_dump isn't doing the
right things to make the old situation morph into the new one. Want to
write a patch?

regards, tom lane

On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

Hmmmm...actually. It's because I have a user called 'support' and a
group called 'support'.

It's possible to support this: the group
and the user will now really be the same entity, ie a role that has both
its own login privileges and members.

Assuming you actually want to unify the two objects. That might well be
the common case, but will it always be true?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:

It's possible to support this: the group
and the user will now really be the same entity, ie a role that has both
its own login privileges and members.

Assuming you actually want to unify the two objects. That might well be
the common case, but will it always be true?

As compared to what? I didn't like the notion of auto-renaming one of
the roles, if that's what you're suggesting. That seems well outside
pg_dump's charter.

regards, tom lane

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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.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

How about an option to map groups whose names conflict with user names
using a prefix mechanism?

e.g. --map-conflicting-groups=gr_

Then in Christopher's example his support group would become the role
gr_support.

No bad, have to change some application code then as well...

Chris

On Tue, Jan 24, 2006 at 10:42:17AM -0500, Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote:

It's possible to support this: the group
and the user will now really be the same entity, ie a role that has both
its own login privileges and members.

Assuming you actually want to unify the two objects. That might well be
the common case, but will it always be true?

As compared to what? I didn't like the notion of auto-renaming one of
the roles, if that's what you're suggesting. That seems well outside
pg_dump's charter.

If you want something renamed, you can handle that case by just renaming
it before you do the dump, but it would be nice if pg_dump would raise a
nice big warning when this condition exists so you're aware of it. Or
maybe even refuse to run unless you supply some command line option to
over-ride.

I don't think we should morph the two together by default either,
because that's very possibly not what the user originally intended.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461