Re: Bug#387256: pgadmin3: missing schema parameter
От | Raphaël Enrici |
---|---|
Тема | Re: Bug#387256: pgadmin3: missing schema parameter |
Дата | |
Msg-id | 451B8523.1040302@club-internet.fr обсуждение исходный текст |
Ответ на | Re: Bug#387256: pgadmin3: missing schema parameter during backup ("Dave Page" <dpage@vale-housing.co.uk>) |
Ответы |
Re: Bug#387256: pgadmin3: missing schema parameter during backup
|
Список | pgadmin-hackers |
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 >>
В списке pgadmin-hackers по дате отправления: