Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database
Date
Msg-id CA+TgmoYNRV-NZvDSMk_Vra1=fZEVpWf8cGWP-bFC-0_qVRftag@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Aug 2, 2016 at 5:42 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> Moving to -hackers since this is getting into details
>
> Bug Report # 14247
>
> On Tue, Aug 2, 2016 at 4:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> > Do you have an opinion on this following?
>>
>> I think the real problem in this area is that the division of labor
>> we have between pg_dump and pg_dumpall isn't very good for real-world
>> use cases.
>
>
> I won't disagree here.
>
>>
>>   I'm not at all sure what a better answer would look like.
>> But I'd rather see us take two steps back and consider the issue
>> holistically instead of trying to band-aid individual misbehaviors.
>>
>> The fact that pg_dump is emitting COMMENT ON DATABASE at all is
>> fundamentally wrong given the existing division-of-labor decisions,
>> namely that pg_dump is responsible for objects within a database
>> not for database-level properties.

I think a while back somebody had the idea of making COMMENT ON
CURRENT_DATABASE or COMMENT ON CURRENT DATABASE work, which seems like
an elegant solution to me.  Of course, I just work here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New version numbering practices
Next
From: Robert Haas
Date:
Subject: Re: [Patch] RBTree iteration interface improvement