Re: [HACKERS] Weird pg_dumpall bug?
On Tue, Jan 24, 2006 at 10:42:17AM -0500, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Weird pg_dumpall bug?
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Weird pg_dumpall bug?
Peter Eisentraut <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Weird pg_dumpall bug?
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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Weird pg_dumpall bug?
Andrew Dunstan <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Weird pg_dumpall bug?
On Tue, 2006-01-24 at 10:05 -0500, Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > > H...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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Weird pg_dumpall bug?
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > H...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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Weird pg_dumpall bug?
On Tue, 2006-01-24 at 09:44 -0500, Stephen Frost wrote: > * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote: > > H...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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Weird pg_dumpall bug?
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote: > H...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 signature.asc Description: Digital signature
[HACKERS] Weird pg_dumpall bug?
I did a dump of a 7.4.11 database using the 8.1.2 pg_dumpall. I got this at the top of the dump: ... ... CREATE ROLE support; ALTER ROLE support WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'md5'; ... ... CREATE ROLE support; ALTER ROLE support WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN; ... ... It dumped the "support" role twice! Any ideas? H...actually. It's because I have a user called 'support' and a group called 'support'. Seems like it needs a fix... Chris ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
