Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Nov 8, 2017 at 8:48 AM, Robert Haas wrote: > On Tue, Nov 7, 2017 at 4:35 AM, Haribabu Kommi > wrote: > > The newly added option is not recommended to be used in normal cases and > > it is used only for upgrade utilities. > > I don't know

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Tue, Nov 7, 2017 at 4:35 AM, Haribabu Kommi wrote: > The newly added option is not recommended to be used in normal cases and > it is used only for upgrade utilities. I don't know why it couldn't be used in normal cases. That seems like a totally legitimate thing

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Thu, Oct 26, 2017 at 10:01 PM, Robert Haas wrote: > On Mon, Oct 23, 2017 at 7:36 AM, Haribabu Kommi > wrote: > > Apologies for not providing much details. > > > > pg_dumpall is used to produce the following statements for database, > > > >

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Mon, Oct 23, 2017 at 7:36 AM, Haribabu Kommi wrote: > Apologies for not providing much details. > > pg_dumpall is used to produce the following statements for database, > > "Create database" (other than default database) or > "Alter database set tablespace" for

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Sun, Oct 22, 2017 at 3:08 AM, Robert Haas wrote: > On Sat, Oct 21, 2017 at 1:30 AM, Haribabu Kommi > wrote: > > Before refactoring, pg_dumpall doesn't print "create database" commands > > for both tempalte1 and postgres database, but on the

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Sat, Oct 21, 2017 at 1:30 AM, Haribabu Kommi wrote: > Before refactoring, pg_dumpall doesn't print "create database" commands > for both tempalte1 and postgres database, but on the other hand pg_dump > dump the create database commands with --create option. > > To

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Fri, Oct 6, 2017 at 12:29 AM, Robert Haas wrote: > On Wed, Oct 4, 2017 at 3:40 AM, Haribabu Kommi > wrote: > > There are some differences in handling database objects > > between pg_dump and pg_dumpall, To retain both pg_dump > > and

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Oct 4, 2017 at 3:40 AM, Haribabu Kommi wrote: > There are some differences in handling database objects > between pg_dump and pg_dumpall, To retain both pg_dump > and pg_dumpall behavior even after refactoring, this option > is added. Currently this option is

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Sat, Sep 30, 2017 at 3:31 AM, Robert Haas wrote: > On Fri, Sep 29, 2017 at 12:44 AM, Vaishnavi Prabakaran > wrote: > > Option name "--enable-pgdumpall-behaviour" is very generic > > Yeah, that's a terrible name, at least in my opinion. >

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Fri, Sep 29, 2017 at 12:44 AM, Vaishnavi Prabakaran wrote: > Option name "--enable-pgdumpall-behaviour" is very generic Yeah, that's a terrible name, at least in my opinion. > and it is better > to rename it to something that reflects its functionality like >

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Hi, On Sat, Sep 9, 2017 at 1:29 PM, Haribabu Kommi wrote: > > Fixed patch is attached. > Patch applies and has lot of noise due to indent with spaces. I did ran regression tests located in - src/test/regress, src/test/modules/test_pg_dump, src/bin/pg_dump,

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Fri, Sep 8, 2017 at 10:24 AM, Thomas Munro wrote: > On Mon, Aug 21, 2017 at 4:35 PM, Haribabu Kommi > wrote: > > On Tue, Aug 15, 2017 at 7:29 AM, Peter Eisentraut > > wrote: > >> On 4/4/17 01:06,

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Mon, Aug 21, 2017 at 4:35 PM, Haribabu Kommi wrote: > On Tue, Aug 15, 2017 at 7:29 AM, Peter Eisentraut > wrote: >> On 4/4/17 01:06, Haribabu Kommi wrote: >> > Both pg_dump and pg_upgrade tests are passed. Updated patch attached >> >

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Tue, Aug 15, 2017 at 7:29 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/4/17 01:06, Haribabu Kommi wrote: > > Both pg_dump and pg_upgrade tests are passed. Updated patch attached > > I will add this patch to the next commitfest. > > This patch needs to be rebased for

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On 4/4/17 01:06, Haribabu Kommi wrote: > Both pg_dump and pg_upgrade tests are passed. Updated patch attached > I will add this patch to the next commitfest. This patch needs to be rebased for the upcoming commit fest. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Thu, Mar 30, 2017 at 12:00 PM, Haribabu Kommi wrote: > > > On Wed, Mar 29, 2017 at 11:04 PM, Andreas Karlsson > wrote: > >> On 03/29/2017 05:43 AM, Haribabu Kommi wrote: >> > Updated patch attached. >> >> I get a test failure in the pg_upgrade

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Mar 29, 2017 at 11:04 PM, Andreas Karlsson wrote: > On 03/29/2017 05:43 AM, Haribabu Kommi wrote: > > Updated patch attached. > > I get a test failure in the pg_upgrade tests, but I do not have time right > now to investigate. > > The failing test is "Restoring

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On 03/29/2017 05:43 AM, Haribabu Kommi wrote: > Updated patch attached. I get a test failure in the pg_upgrade tests, but I do not have time right now to investigate. The failing test is "Restoring database schemas in the new cluster". I get the following in the log: command:

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Tue, Mar 28, 2017 at 12:50 AM, Andreas Karlsson wrote: > Hi, > > Here is my review. I agree with the goal of the refactoring, as we want to > make it easier to dump all the properties for the database object. But I > think we need to solve the issues with the special casing

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Hi, Here is my review. I agree with the goal of the refactoring, as we want to make it easier to dump all the properties for the database object. But I think we need to solve the issues with the special casing of postgres and template1 which I personally would find very surprising if pg_dump

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On 03/21/2017 08:02 AM, Haribabu Kommi wrote: Solution -1) Just ignore dumping these CREATE DATABASE commands and provide the user information in the documentation to create "postgres" and "template1" database in the target in case if they don't exist. If this kind of cases are very rare.

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Because of this refactor handing of database objects between pg_dump and pg_dumpall, the latest pg_dump tap tests are failing in the following scenarios. 1. CREATE DATABASE postgres Before this patch, the pg_dump uses to dump the CREATE DATABASE command of postgres but not by pg_dumpall. During

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Wed, Mar 1, 2017 at 12:59 PM, Haribabu Kommi wrote: > > Patch attached. Still some more docs needs to be added. > Updated patch attached to resolve the conflicts with following commit. commit 9a83d56b38c870ce47b7651385ff2add583bf136 Author: Simon Riggs