Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 9:33 AM, Tom Lane wrote: > Uh ... what in that is creating the already-extant parent? /me looks embarrassed. Never mind. I didn't read what you wrote carefully enough. >> I think one answer to the original complaint might be to add a new >> flag to

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Robert Haas writes: > On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote: >> You could argue that it would be better for pg_dump to emit something >> like >> >> CREATE TABLE c (...); >> ALTER TABLE c INHERIT p; >> >> so that if p isn't around, at least c

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote: > Jeevan Ladhe writes: >> On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat < >>> We add PARTITION OF clause for a table which is partition, so if the >>> parent is not present while restoring, the

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Jeevan Ladhe writes: > On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat < >> We add PARTITION OF clause for a table which is partition, so if the >> parent is not present while restoring, the restore is going to fail. > +1 > But, similarly for inheritance if we dump

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > We add PARTITION OF clause for a table which is partition, so if the > parent is not present while restoring, the restore is going to fail. +1 But, similarly for inheritance if we dump a child table,

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 3:05 AM, Tom Lane wrote: > > We should make sure that pg_dump behaves sanely when dumping just > some elements of a partition tree, of course. And for that matter, > pg_restore ought to be able to successfully restore just some elements > out of a an

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 2:06 AM, Robert Haas wrote: > On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe > wrote: >>> Current pg_dump --exclude-table option excludes partitioned relation >>> and dumps all its child relations and vice versa for

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Robert Haas writes: > On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe > wrote: >> Also, I can see similar issue exists with inheritance. > That's a pretty insightful comment which makes me think that this > isn't properly categorized as a bug.

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 4:21 AM, Jeevan Ladhe wrote: >> Current pg_dump --exclude-table option excludes partitioned relation >> and dumps all its child relations and vice versa for --table option, which >> I think is incorrect. >> >> In this case we might need to

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 3:51 PM, Ashutosh Bapat wrote: > On Tue, May 9, 2017 at 2:59 PM, Amit Langote > wrote: >> Hi Amul, >> >> On 2017/05/09 16:13, amul sul wrote: >>> Hi, >>> >>> Current pg_dump --exclude-table option excludes

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 2:59 PM, Amit Langote wrote: > Hi Amul, > > On 2017/05/09 16:13, amul sul wrote: >> Hi, >> >> Current pg_dump --exclude-table option excludes partitioned relation >> and dumps all its child relations and vice versa for --table option, which >>

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi Amit, Ashutosh, On Tue, May 9, 2017 at 3:29 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Tue, May 9, 2017 at 3:13 PM, Amit Langote > wrote: > > On 2017/05/09 17:21, Jeevan Ladhe wrote: > >> On Tue, May 9, 2017 at 12:43 PM, amul sul

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 3:13 PM, Amit Langote wrote: > On 2017/05/09 17:21, Jeevan Ladhe wrote: >> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: >>> Current pg_dump --exclude-table option excludes partitioned relation >>> and dumps all its

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On 2017/05/09 17:21, Jeevan Ladhe wrote: > On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: >> Current pg_dump --exclude-table option excludes partitioned relation >> and dumps all its child relations and vice versa for --table option, which >> I think is incorrect. >> >> In

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: > Hi, > > Current pg_dump --exclude-table option excludes partitioned relation > and dumps all its child relations and vice versa for --table option, which > I think is incorrect. > > In this case we might need to explore all

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi Amul, On 2017/05/09 16:13, amul sul wrote: > Hi, > > Current pg_dump --exclude-table option excludes partitioned relation > and dumps all its child relations and vice versa for --table option, which > I think is incorrect. I agree that `pg_dump -t partitioned_table` should dump all of its

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

In my last email by mistake I attached Amul's patch itself. Please find attached patch extending the fix to inheritance relations. Regards, Jeevan Ladhe On Tue, May 9, 2017 at 1:51 PM, Jeevan Ladhe wrote: > Hi, > > On Tue, May 9, 2017 at 12:43 PM, amul sul

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi, On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: > Hi, > > Current pg_dump --exclude-table option excludes partitioned relation > and dumps all its child relations and vice versa for --table option, which > I think is incorrect. > > In this case we might need to explore

[HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi, Current pg_dump --exclude-table option excludes partitioned relation and dumps all its child relations and vice versa for --table option, which I think is incorrect. In this case we might need to explore all partitions and exclude or include from dump according to given pg_dump option,

Re: [HACKERS] Bug in pg_dump

On Wed, Mar 4, 2015 at 2:03 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Wed, Mar 4, 2015 at 6:48 AM, Peter Eisentraut pete...@gmx.net wrote: - set up basic scaffolding for TAP tests in src/bin/pg_dump Agreed. - write a Perl function that can create an extension on the fly, given

Re: [HACKERS] Bug in pg_dump

On 3/1/15 2:17 PM, Stephen Frost wrote: Peter, if you have a minute, could you take a look at this thread and discussion of having TAP tests under src/test/modules which need to install an extension? I think it's something we certainly want to support but I'm not sure it's a good idea to just

Re: [HACKERS] Bug in pg_dump

On Wed, Mar 4, 2015 at 6:48 AM, Peter Eisentraut pete...@gmx.net wrote: - set up basic scaffolding for TAP tests in src/bin/pg_dump Agreed. - write a Perl function that can create an extension on the fly, given name, C code, SQL code I am perplex about that. Where would the SQL code or C

Re: [HACKERS] Bug in pg_dump

On Tue, Mar 3, 2015 at 4:57 AM, Stephen Frost sfr...@snowman.net wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost sfr...@snowman.net wrote: Please see the latest version of this, attached. I've removed the left join, re-used the

Re: [HACKERS] Bug in pg_dump

* Michael Paquier (michael.paqu...@gmail.com) wrote: On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost sfr...@snowman.net wrote: Please see the latest version of this, attached. I've removed the left join, re-used the 'query' buffer (instead of destroying and recreating it), and added a bit of

Re: [HACKERS] Bug in pg_dump

Michael, * Stephen Frost (sfr...@snowman.net) wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: The thing is that we must absolutely wait for *all* the TableInfoData of all the extensions to be created because we need to mark the dependencies between them, and even my last patch,

Re: [HACKERS] Bug in pg_dump

On Mon, Mar 2, 2015 at 6:27 AM, Stephen Frost sfr...@snowman.net wrote: Please see the latest version of this, attached. I've removed the left join, re-used the 'query' buffer (instead of destroying and recreating it), and added a bit of documentation, along with a note in the commit message

Re: [HACKERS] Bug in pg_dump

On Sun, Mar 1, 2015 at 1:09 AM, Stephen Frost sfr...@snowman.net wrote: Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: + /* + * Query all the foreign key dependencies for all the extension + * tables found

Re: [HACKERS] Bug in pg_dump

Michael, * Stephen Frost (sfr...@snowman.net) wrote: * Michael Paquier (michael.paqu...@gmail.com) wrote: Subject: [PATCH 2/3] Make prove_check install contents of current directory as well This is really an independent thing, no? I don't see any particular problem with it, for

Re: [HACKERS] Bug in pg_dump

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: The thing is that we must absolutely wait for *all* the TableInfoData of all the extensions to be created because we need to mark the dependencies between them, and even my last patch, or even with what you are proposing we may

Re: [HACKERS] Bug in pg_dump

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: Subject: [PATCH 2/3] Make prove_check install contents of current directory as well This is really an independent thing, no? I don't see any particular problem with it, for my part. Yes, that's an independent thing, but

Re: [HACKERS] Bug in pg_dump

Michael, all, * Michael Paquier (michael.paqu...@gmail.com) wrote: On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold gilles.dar...@dalibo.com wrote: This is a far better patch and the test to export/import of the postgis_topology extension works great for me. Thanks for the work.

Re: [HACKERS] Bug in pg_dump

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: + /* + * Query all the foreign key dependencies for all the extension + * tables found previously. Only tables whose data need to be + * have to

Re: [HACKERS] Bug in pg_dump

On Sat, Feb 28, 2015 at 12:29 AM, Gilles Darold gilles.dar...@dalibo.com wrote: Le 26/02/2015 12:41, Michael Paquier a écrit : On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold gilles.dar...@dalibo.com wrote: This is a far better patch and the test to export/import of the postgis_topology

Re: [HACKERS] Bug in pg_dump

On Thu, Feb 26, 2015 at 08:41:46PM +0900, Michael Paquier wrote: On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold gilles.dar...@dalibo.com wrote: This is a far better patch and the test to export/import of the postgis_topology extension works great for me. Thanks for the work. Attached

Re: [HACKERS] Bug in pg_dump

Le 26/02/2015 12:41, Michael Paquier a écrit : On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold gilles.dar...@dalibo.com wrote: This is a far better patch and the test to export/import of the postgis_topology extension works great for me. Thanks for the work. Attached is a patch that uses an

Re: [HACKERS] Bug in pg_dump

On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold gilles.dar...@dalibo.com wrote: This is a far better patch and the test to export/import of the postgis_topology extension works great for me. Thanks for the work. Attached is a patch that uses an even better approach by querying only once all

Re: [HACKERS] Bug in pg_dump

Le 24/02/2015 05:40, Michael Paquier a écrit : On Tue, Feb 24, 2015 at 2:17 AM, Gilles Darold gilles.dar...@dalibo.com mailto:gilles.dar...@dalibo.com wrote: Looks great to me, I have tested with the postgis_topology extension everything works fine. Actually, after looking more

Re: [HACKERS] Bug in pg_dump

Le 17/02/2015 14:44, Michael Paquier a écrit : On Tue, Jan 20, 2015 at 8:06 PM, Gilles Darold gilles.dar...@dalibo.com wrote: Le 19/01/2015 14:41, Robert Haas a écrit : On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold gilles.dar...@dalibo.com wrote: I attach a patch that solves the issue in

Re: [HACKERS] Bug in pg_dump

On Tue, Feb 24, 2015 at 2:17 AM, Gilles Darold gilles.dar...@dalibo.com wrote: Looks great to me, I have tested with the postgis_topology extension everything works fine. Actually, after looking more in depth at the internals of pg_dump I think that both patches are wrong (did that yesterday

Re: [HACKERS] Bug in pg_dump

On Tue, Jan 20, 2015 at 8:06 PM, Gilles Darold gilles.dar...@dalibo.com wrote: Le 19/01/2015 14:41, Robert Haas a écrit : On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold gilles.dar...@dalibo.com wrote: I attach a patch that solves the issue in pg_dump, let me know if it might be included in

Re: [HACKERS] Bug in pg_dump

Le 19/01/2015 14:41, Robert Haas a écrit : On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold gilles.dar...@dalibo.com wrote: I attach a patch that solves the issue in pg_dump, let me know if it might be included in Commit Fest or if the three other solutions are a better choice. I think a fix

Re: [HACKERS] Bug in pg_dump

On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold gilles.dar...@dalibo.com wrote: I attach a patch that solves the issue in pg_dump, let me know if it might be included in Commit Fest or if the three other solutions are a better choice. I think a fix in pg_dump is appropriate, so I'd encourage

Re: [HACKERS] Bug in pg_dump

On 16/01/2015 01:06, Jim Nasby wrote: On 1/15/15 5:26 AM, Gilles Darold wrote: Hello, There's a long pending issue with pg_dump and extensions that have table members with foreign keys. This was previously reported in this thread

Re: [HACKERS] Bug in pg_dump

On 1/15/15 5:26 AM, Gilles Darold wrote: Hello, There's a long pending issue with pg_dump and extensions that have table members with foreign keys. This was previously reported in this thread

[HACKERS] Bug in pg_dump

Hello, There's a long pending issue with pg_dump and extensions that have table members with foreign keys. This was previously reported in this thread http://www.postgresql.org/message-id/ca+tgmoyvzkadmgh_8el7uvm472geru0b4pnnfjqye6ss1k9...@mail.gmail.com and discuss by Robert. All PostgreSQL

[HACKERS] Bug in pg_dump

The example from Tom Lane below results in a database which is not possible to correctly dump using pg_dump. The view v1 strangely becomes a table in the dump output?! It's probably a quite useless database to dump in the first place, but that is no excuse to generate an invalid dump, it would

Re: [HACKERS] Bug in pg_dump

On 2011-01-13 11:31 AM +0200, Joel Jacobson wrote: The example from Tom Lane below results in a database which is not possible to correctly dump using pg_dump. The view v1 strangely becomes a table in the dump output?! CREATE RULE _RETURN AS ON SELECT TO v1 DO INSTEAD SELECT v2.f1, v2.f2

Re: [HACKERS] Bug in pg_dump

* Joel Jacobson wrote: The example from Tom Lane below results in a database which is not possible to correctly dump using pg_dump. The view v1 strangely becomes a table in the dump output?! This is no bug, it's a feature (tm). pg_dump is clever enough to detect the circular dependency and

Re: [HACKERS] Bug in pg_dump

Excerpts from Joel Jacobson's message of jue ene 13 06:31:06 -0300 2011: The example from Tom Lane below results in a database which is not possible to correctly dump using pg_dump. I wouldn't care too much about that particular case -- you can't query any of the views either. -- Álvaro

Re: [HACKERS] Bug in pg_dump

Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Joel Jacobson's message of jue ene 13 06:31:06 -0300 2011: The example from Tom Lane below results in a database which is not possible to correctly dump using pg_dump. I wouldn't care too much about that particular case -- you

Re: [HACKERS] Bug in pg_dump -c with casts

Actually, scratch that - I'm wrong... It appeared separately from the other DROP commands... Chris Christopher Kings-Lynne wrote: Hi, Playing around with this MySQL compatibility library, I noticed that pg_dump -c does not emit DROP commands for casts. Seems like a bug...? Chris

[HACKERS] Bug in pg_dump -c with casts

Hi, Playing around with this MySQL compatibility library, I noticed that pg_dump -c does not emit DROP commands for casts. Seems like a bug...? Chris ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire

Re: [HACKERS] bug in pg_dump ALTER DATABASE

As part of my testing, I noticed this bug. My database has a search_path set in the database vars. It dumps lik ethis: DROP DATABASE usa; CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING = 'LATIN1'; ALTER DATABASE usa SET search_path TO 'public, contrib'; Notice the

Re: [HACKERS] bug in pg_dump ALTER DATABASE

So what are we going to do about this problem? The pg_settings view does not have enough information to determine it generically. (It only says 'string', not 'list'...) I propose that we modify pg_dumpall to hard-code the set of list-type GUC variables for each backend version. The current

[HACKERS] bug in pg_dump ALTER DATABASE

As part of my testing, I noticed this bug. My database has a search_path set in the database vars. It dumps lik ethis: DROP DATABASE usa; CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING = 'LATIN1'; ALTER DATABASE usa SET search_path TO 'public, contrib'; Notice the

[HACKERS] Bug in pg_dump 7.4

Part of dump file: CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT nextval('doc.seq_doc_id'::text) CONSTRAINT cnst_chk_doc_id CHECK fn_chk_doc_id(VALUE); It should look like this: CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT nextval('doc.seq_doc_id'::text)

Re: [HACKERS] Bug in pg_dump 7.4

CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT nextval('doc.seq_doc_id'::text) CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ; I did not notice any similar error report on the list, so I believe that this is not fixed yet ? It comes out right for me in 7.4.2.

Re: [HACKERS] Bug in pg_dump 7.4

Rod Taylor [EMAIL PROTECTED] writes: CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT nextval('doc.seq_doc_id'::text) CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ; It comes out right for me in 7.4.2. AFAICT the relevant fix was well before 7.4 release: 2003-10-04 14:22

Re: [HACKERS] Bug in pg_dump 7.4

On Thu, May 06, 2004 at 10:17:31 -0400, Rod Taylor [EMAIL PROTECTED] wrote: CREATE DOMAIN doc_ident AS bigint NOT NULL DEFAULT nextval('doc.seq_doc_id'::text) CONSTRAINT cnst_chk_doc_id CHECK ( fn_chk_doc_id(VALUE) ) ; I did not notice any similar error report on the list, so I

Re: [HACKERS] Bug in pg_dump 7.4

- From: Bruno Wolff III [EMAIL PROTECTED] To: Rod Taylor [EMAIL PROTECTED] Cc: Darko Prenosil [EMAIL PROTECTED]; PostgreSQL Development [EMAIL PROTECTED] Sent: Thursday, May 06, 2004 6:41 PM Subject: Re: [HACKERS] Bug in pg_dump 7.4 On Thu, May 06, 2004 at 10:17:31 -0400, Rod Taylor [EMAIL

[HACKERS] bug in pg_dump with GRANT/REVOKE

I'm running postgres 6.5.3 and 7.0.3 and pg_dump gives me the following output: DROP TABLE genrenametable; CREATE TABLE genrenametable ( genreid int4, name character varying(128), parentgenre int4, enabled bool DEFAULT 'f' NOT NULL ); REVOKE ALL on