Обсуждение: Re: Bug#387256: pgadmin3: missing schema parameter during backup
Hi Luca, sorry for the delay. I confim I can reproduce this and the the solution you propose seems to be viable. I've managed to produce a patch for it I'm sending upstream so that it can be validated. @pgadmin-hackers: Luca is facing the issue described below. In short, when you try to export a table from a schema A which is also present in a schema B, both the table are tried for backup. The patch attached forces the table's schema name to be passed as an argument to pg_dump. Something off topic, @Luca: it seems you are using an old backport of pgAdmin III although apt prefers unstable. Any reason for not upgrading to latest 1.4.3-1? Regards, Raph Luca Arzeni wrote: > Package: pgadmin3 > Version: 1.4.0-0.3.release.sarge.2 > Severity: normal > Tags: patch > > I define two or more schemas in a database (say schema1 and > schema2) and restrict user access to them (say user1 can work on schema1 > only, and user2 can work on schema2 only). > > user1 creates table "addressbook" in schema1 > user2 creates table "addressbook" in schema2 > > They work fine on their tables, but if user1 select table addressbook in > pgadmin3 object browser and tries to backup that table, pgadmin3 refuses > to execute the requested operation saying that user1 has not enough > rights to access table addressbook. > > Problem is: > pgadmin3 invokes command line tool pg_dump, without > specifying the --schema=schema1 option in the command line. > > Solution/Patch: > add --schema=schemaNameOfTheSelectedTable to the command line of pg_dump > > > -- System Information: > Debian Release: 3.1 > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.11.5-686-smp-p4-w4l-himem > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > > Versions of packages pgadmin3 depends on: > ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an > ii libgcc1 1:3.4.3-13sarge1 GCC support library > ii libpq3 7.4.7-6sarge2 PostgreSQL C client library > ii libssl0.9.7 0.9.7e-3sarge2 SSL shared libraries > ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3 > ii libwxgtk2.6-0 2.6.1.0-0.pgadmin3.sarge.1 wxWidgets Cross-platform C++ GUI t > ii pgadmin3-data 1.4.0-0.3.release.sarge.2 Graphical administration tool for > > -- no debconf information > > > Index: pgadmin3-1.4.3/src/frm/frmBackup.cpp =================================================================== --- pgadmin3-1.4.3/src/frm/frmBackup.cpp (révision 5401) +++ pgadmin3-1.4.3/src/frm/frmBackup.cpp (copie de travail) @@ -251,8 +251,10 @@ pgSchema *schema=0; if (object->GetMetaType() == PGM_SCHEMA) schema =(pgSchema*)object; - else if (object->GetMetaType() == PGM_TABLE) + else if (object->GetMetaType() == PGM_TABLE) { cmd.Append(wxT(" -t ") + ((pgTable*)object)->GetQuotedIdentifier()); + cmd.Append(wxT(" -n ") + ((pgTable*)object)->GetSchema()->GetQuotedIdentifier()); + } if (schema) cmd.Append(wxT(" -n ") + schema->GetQuotedIdentifier());
Thanks, tweaked version of the patch applied for 1.6. Regards, Dave > -----Original Message----- > From: pgadmin-hackers-owner@postgresql.org > [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of > Raphaël Enrici > Sent: 27 September 2006 21:44 > To: PgAdmin Hackers > Cc: Luca Arzeni; 387256-forwarded@bugs.debian.org > Subject: Re: [pgadmin-hackers] Bug#387256: pgadmin3: missing > schema parameter during backup > > Hi Luca, > > sorry for the delay. I confim I can reproduce this and the > the solution > you propose seems to be viable. I've managed to produce a patch for it > I'm sending upstream so that it can be validated. > > @pgadmin-hackers: Luca is facing the issue described below. In short, > when you try to export a table from a schema A which is also > present in > a schema B, both the table are tried for backup. The patch attached > forces the table's schema name to be passed as an argument to pg_dump. > > Something off topic, @Luca: it seems you are using an old backport of > pgAdmin III although apt prefers unstable. Any reason for not > upgrading > to latest 1.4.3-1? > > Regards, > Raph > > Luca Arzeni wrote: > > Package: pgadmin3 > > Version: 1.4.0-0.3.release.sarge.2 > > Severity: normal > > Tags: patch > > > > I define two or more schemas in a database (say schema1 and > > schema2) and restrict user access to them (say user1 can > work on schema1 > > only, and user2 can work on schema2 only). > > > > user1 creates table "addressbook" in schema1 > > user2 creates table "addressbook" in schema2 > > > > They work fine on their tables, but if user1 select table > addressbook in > > pgadmin3 object browser and tries to backup that table, > pgadmin3 refuses > > to execute the requested operation saying that user1 has not enough > > rights to access table addressbook. > > > > Problem is: > > pgadmin3 invokes command line tool pg_dump, without > > specifying the --schema=schema1 option in the command line. > > > > Solution/Patch: > > add --schema=schemaNameOfTheSelectedTable to the command > line of pg_dump > > > > > > -- System Information: > > Debian Release: 3.1 > > APT prefers unstable > > APT policy: (500, 'unstable') > > Architecture: i386 (i686) > > Kernel: Linux 2.6.11.5-686-smp-p4-w4l-himem > > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > > > > Versions of packages pgadmin3 depends on: > > ii libc6 2.3.2.ds1-22 GNU C Library: > Shared libraries an > > ii libgcc1 1:3.4.3-13sarge1 GCC support library > > ii libpq3 7.4.7-6sarge2 PostgreSQL C > client library > > ii libssl0.9.7 0.9.7e-3sarge2 SSL shared libraries > > ii libstdc++5 1:3.3.5-13 The GNU > Standard C++ Library v3 > > ii libwxgtk2.6-0 2.6.1.0-0.pgadmin3.sarge.1 wxWidgets > Cross-platform C++ GUI t > > ii pgadmin3-data 1.4.0-0.3.release.sarge.2 Graphical > administration tool for > > > > -- no debconf information > > > > > > >
Dave Page wrote: > Thanks, tweaked version of the patch applied for 1.6. Thanks Dave, I'll apply my patch to 1.4.3 in debian rapidly. If I understand well, 1.4.3 is the last version which will ever be released in the 1.4.x branch. Right? If not, maybe we should add it to /branches/REL-1_4_0_PATCHES? Regards, Raph > > Regards, Dave > > >>-----Original Message----- >>From: pgadmin-hackers-owner@postgresql.org >>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of >>Raphaël Enrici >>Sent: 27 September 2006 21:44 >>To: PgAdmin Hackers >>Cc: Luca Arzeni; 387256-forwarded@bugs.debian.org >>Subject: Re: [pgadmin-hackers] Bug#387256: pgadmin3: missing >>schema parameter during backup >> >>Hi Luca, >> >>sorry for the delay. I confim I can reproduce this and the >>the solution >>you propose seems to be viable. I've managed to produce a patch for it >>I'm sending upstream so that it can be validated. >> >>@pgadmin-hackers: Luca is facing the issue described below. In short, >>when you try to export a table from a schema A which is also >>present in >>a schema B, both the table are tried for backup. The patch attached >>forces the table's schema name to be passed as an argument to pg_dump. >> >>Something off topic, @Luca: it seems you are using an old backport of >>pgAdmin III although apt prefers unstable. Any reason for not >>upgrading >>to latest 1.4.3-1? >> >>Regards, >>Raph >> >>Luca Arzeni wrote: >> >>>Package: pgadmin3 >>>Version: 1.4.0-0.3.release.sarge.2 >>>Severity: normal >>>Tags: patch >>> >>>I define two or more schemas in a database (say schema1 and >>>schema2) and restrict user access to them (say user1 can >> >>work on schema1 >> >>>only, and user2 can work on schema2 only). >>> >>>user1 creates table "addressbook" in schema1 >>>user2 creates table "addressbook" in schema2 >>> >>>They work fine on their tables, but if user1 select table >> >>addressbook in >> >>>pgadmin3 object browser and tries to backup that table, >> >>pgadmin3 refuses >> >>>to execute the requested operation saying that user1 has not enough >>>rights to access table addressbook. >>> >>>Problem is: >>>pgadmin3 invokes command line tool pg_dump, without >>>specifying the --schema=schema1 option in the command line. >>> >>>Solution/Patch: >>>add --schema=schemaNameOfTheSelectedTable to the command >> >>line of pg_dump >>
> -----Original Message----- > From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] > Sent: 28 September 2006 09:18 > To: Dave Page > Cc: PgAdmin Hackers; Luca Arzeni; 387256-forwarded@bugs.debian.org > Subject: Re: [pgadmin-hackers] Bug#387256: pgadmin3: missing > schema parameter during backup > > Dave Page wrote: > > Thanks, tweaked version of the patch applied for 1.6. > > Thanks Dave, I'll apply my patch to 1.4.3 in debian rapidly. If I > understand well, 1.4.3 is the last version which will ever be > released > in the 1.4.x branch. Right? If not, maybe we should add it to > /branches/REL-1_4_0_PATCHES? Yes, there will be no more 1.4 releases. If you feel it's worth maintaining the backports for OS bundled copies though, thenI'm happy to talk about that - though I won't be maintaining those old branches so you'd have to volunteer :-) Regards, Dave.
Dave Page wrote: > > > >>-----Original Message----- >>From: Raphaël Enrici [mailto:blacknoz@club-internet.fr] >>Sent: 28 September 2006 09:18 >>To: Dave Page >>Cc: PgAdmin Hackers; Luca Arzeni; 387256-forwarded@bugs.debian.org >>Subject: Re: [pgadmin-hackers] Bug#387256: pgadmin3: missing >>schema parameter during backup >> >>Dave Page wrote: >> >>>Thanks, tweaked version of the patch applied for 1.6. >> >>Thanks Dave, I'll apply my patch to 1.4.3 in debian rapidly. If I >>understand well, 1.4.3 is the last version which will ever be >>released >>in the 1.4.x branch. Right? If not, maybe we should add it to >>/branches/REL-1_4_0_PATCHES? > > > Yes, there will be no more 1.4 releases. If you feel it's worth maintaining the backports for OS bundled copies though,then I'm happy to talk about that - though I won't be maintaining those old branches so you'd have to volunteer :-) oooh. Our emails crossed (see my last post concerning the other debian bug). Ok, we should definitely discuss about this as I need to maintain backports at least for the debian package. So, I think I have no real choice but the one to volunteer :) Anybody else on the list wishing to help concerning this? Cheers, Raph