|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
/* --create implies --set-db-properties, for now anyway */
dopt.set_db_properties = 1;
If somebody actually asks for --no-set-db-properties, we can add that
regards, tom lane
|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|