Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database
Date: 2016-08-05 00:28:26
Message-ID: CAMsr+YGkEy=GvgA6BYpeVCeD53jobn9cNXpdLEU0P56TiMvKfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 5 August 2016 at 05:03, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> ​
> I'm all for an elegant solution here though at some point having a working
> solution now beats waiting for someone to willingly dive more deeply into
> pg_dump. I too seem to recall previous proposals for COMMON ON CURRENT
> DATABASE yet here we are...
>
>
SECURITY LABEL ... ON CURRENT DATABASE is needed too, and has caused
real-world pain.

I tend to agree that adding and using ... ON CURRENT DATABASE is worthwhile
now. It's guaranteed to be at least as correct as what pg_dump emits now.

We do have a horrible mess with how pg_dump handles database level
properties, but I'd rather not try to deal with that at the same time, get
into a long discussion and land up fixing nothing.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message prikshat 2016-08-05 06:41:07 BUG #14280: Error in PostgreSQL - could not extend file "base...": File too large
Previous Message David G. Johnston 2016-08-04 21:03:42 Re: Fwd: [BUGS] BUG #14247: COMMENT is restored on wrong database

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-08-05 00:36:04 Re: New version numbering practices
Previous Message Jim Nasby 2016-08-04 23:46:26 Re: System load consideration before spawning parallel workers