Thread: 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