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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Vaishnavi Prabakaran <vaishnaviprabakaran(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Date: 2018-01-18 22:09:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * As the patch stands, --set-db-properties is implicit when you specify
>> -C, and in fact the patch goes to the trouble of throwing an error if you
>> try to specify both switches. I'm inclined to think this might be a bad
>> idea. What about saying that -C enables emitting CREATE DATABASE and
>> reconnecting to that DB, and independently of that, --set-db-properties
>> enables emitting the additional per-database properties? This seems
>> simpler to understand, more flexible, and less of a change from the
>> previous behavior of -C. On the other hand you could argue that people
>> would always want --set-db-properties with -C and so we're merely
>> promoting carpal tunnel (and errors of omission) if we do it like that.

> I would vigorously agree with that latter argument. I think the
> chances of errors of omission would be very high even if the carpal
> tunnel dangers were ameliorated by giving --set-db-properties a short
> option name.

Fair enough. We'll keep the behavioral change then.

>> If so, maybe we could say "-C implies --set-db-properties by default, but
>> if you really don't want that, you can say -C --no-set-db-properties".

> That seems like a better idea.

What I think I'll do for the moment is make them independent options so
far as the implementation is concerned, but have the command line switch
processing do

/* --create implies --set-db-properties, for now anyway */
if (dopt.outputCreateDB)
dopt.set_db_properties = 1;

If somebody actually asks for --no-set-db-properties, we can add that

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2018-01-18 22:16:56 Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.
Previous Message Alvaro Herrera 2018-01-18 21:43:59 Re: [HACKERS] Proposal: Local indexes for partitioned table