Re: pg_dump selectively ignores extension configuration tables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pg_dump selectively ignores extension configuration tables
Date
Msg-id 20130325151735.GB3699@alvh.no-ip.org
Whole thread Raw
In response to Re: pg_dump selectively ignores extension configuration tables  (Vibhor Kumar <vibhor.kumar@enterprisedb.com>)
Responses Re: pg_dump selectively ignores extension configuration tables  (Vibhor Kumar <vibhor.kumar@enterprisedb.com>)
List pgsql-hackers
Vibhor Kumar escribió:
> On Mar 25, 2013, at 9:56 AM, Joe Conway <mail@joeconway.com> wrote:
>
> > On 03/14/2013 05:23 PM, Joe Conway wrote:
> >> On 03/13/2013 04:16 PM, Dimitri Fontaine wrote:
> >>> Joe Conway <mail@joeconway.com> writes:
> >>>> I think it should dump the user data portion, especially since that
> >>>> matches what pg_dump would do if you did not specify the table or schema.
> >>>
> >>> +1
> >>>
> >>> If you don't have time slots to fix that by then, I will have a look at
> >>> fixing that while in beta.
> >>
> >> Here is a patch against 9.1. If there is agreement with the approach
> >> I'll redo for 9.2 and git head and apply.
> >
> > Any objections before I commit this?
> >
> Since, nobody has picked this one.
>
> If there is no objection,then I can test this patch against 9.1 & 9.2.

Thanks, yes, that would be helpful.  Things to think about are whether
this affect anything other than tables marked as config for any
extension, and whether behavior is sane for them, (i.e. the "condition"
thingy works right etc).

The whole matter of extension configuration table has been rather
tricky to get right ... hopefully we're not ending up with them being
more broken now.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Vibhor Kumar
Date:
Subject: Re: pg_dump selectively ignores extension configuration tables
Next
From: Alvaro Herrera
Date:
Subject: Re: Let's invent a function to report lock-wait-blocking PIDs