Skip site navigation (1) Skip section navigation (2)

Re: Bug#387256: pgadmin3: missing schema parameter during backup

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: Raphaël Enrici <blacknoz(at)club-internet(dot)fr>,"PgAdmin Hackers" <pgadmin-hackers(at)postgresql(dot)org>
Cc: "Luca Arzeni" <l(dot)arzeni(at)iname(dot)com>,<387256-forwarded(at)bugs(dot)debian(dot)org>
Subject: Re: Bug#387256: pgadmin3: missing schema parameter during backup
Date: 2006-09-28 07:38:43
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E40176D0E7@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgadmin-hackers
Thanks, tweaked version of the patch applied for 1.6.

Regards, Dave 

> -----Original Message-----
> From: pgadmin-hackers-owner(at)postgresql(dot)org 
> [mailto:pgadmin-hackers-owner(at)postgresql(dot)org] On Behalf Of 
> Raphaël Enrici
> Sent: 27 September 2006 21:44
> To: PgAdmin Hackers
> Cc: Luca Arzeni; 387256-forwarded(at)bugs(dot)debian(dot)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
> > 
> >  
> > 
> 

In response to

Responses

pgadmin-hackers by date

Next:From: svnDate: 2006-09-28 07:47:07
Subject: SVN Commit by dpage: r5403 - trunk/pgadmin3/i18n/fr_FR
Previous:From: svnDate: 2006-09-28 07:37:24
Subject: SVN Commit by dpage: r5402 - in trunk/pgadmin3: . src/frm

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group