Michael Paquier wrote:
> On Wed, Feb 25, 2015 at 10:30 AM, Alvaro Herrera
> wrote:
> > That looks interesting -- I don't recall seeing it. Does it support
> > more doing than one extension? If so, we could certainly integrate it.
>
> It uses TAP tests to kick pg_dump commands, and I haven't ad
On Wed, Feb 25, 2015 at 10:30 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
> > On Tue, Feb 24, 2015 at 11:55 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > Maybe something in src/test/modules could keep these files so that
> > > pg_dump can be tested. Is anybody intere
Michael Paquier wrote:
> On Tue, Feb 24, 2015 at 11:55 PM, Alvaro Herrera
> wrote:
> > Maybe something in src/test/modules could keep these files so that
> > pg_dump can be tested. Is anybody interested in doing that?
>
> For the patch to fix data dump of extensions that contain tables with FK
On Tue, Feb 24, 2015 at 11:55 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
> > On Tue, Feb 24, 2015 at 3:13 PM, Rushabh Lathia <
> rushabh.lat...@gmail.com>
> > wrote:
>
> > > rushabh@rushabh-centos-vm:dump_test$ cat dump_test--1.0.sql
> > > /* dump_test/dump_test--1.0.sql */
>
> Hm. I thi
Michael Paquier wrote:
> On Tue, Feb 24, 2015 at 3:13 PM, Rushabh Lathia
> wrote:
> > rushabh@rushabh-centos-vm:dump_test$ cat dump_test--1.0.sql
> > /* dump_test/dump_test--1.0.sql */
Hm. I think it would be a good idea to collect these extension files
somewhere so that pg_dump hacking can be
On Tue, Feb 24, 2015 at 3:13 PM, Rushabh Lathia
wrote:
>
> Ok. Looking at above code into getExtensionMembership(). It seems like you
> fix you suggested is not correct. I new table with DEFAULT attribute into
> dump_test extension and pg_dump with binary-upgrade is failing with
> pg_dump: invalid
On Mon, Feb 23, 2015 at 7:45 PM, Michael Paquier
wrote:
>
>
> On Mon, Feb 23, 2015 at 5:57 PM, Rushabh Lathia
> wrote:
> > Thanks to the easy handy testcase, was able to replicate the test
> scenario
> > on my local environment. And yes tbinfo->dobj.ext_member check into
> > getTableAttrs() do f
On Mon, Feb 23, 2015 at 5:57 PM, Rushabh Lathia
wrote:
> Thanks to the easy handy testcase, was able to replicate the test scenario
> on my local environment. And yes tbinfo->dobj.ext_member check into
> getTableAttrs() do fix the issue.
>
> Looking more into pg_dump code what I found that, genera
Thanks to the easy handy testcase, was able to replicate the test scenario
on my local environment. And yes tbinfo->dobj.ext_member check into
getTableAttrs() do fix the issue.
Looking more into pg_dump code what I found that, generally PG don't have
tbinfo->dobj.ext_member check to ignore the obj
On Fri, Feb 20, 2015 at 5:33 AM, Peter Eisentraut wrote:
> On 2/16/15 2:45 AM, Michael Paquier wrote:
>> While looking at the patch to fix pg_dump with extensions containing
>> tables referencing each other, I got surprised by the fact that
>> getTableAttrs tries to dump table attributes even for
On 2/16/15 2:45 AM, Michael Paquier wrote:
> While looking at the patch to fix pg_dump with extensions containing
> tables referencing each other, I got surprised by the fact that
> getTableAttrs tries to dump table attributes even for tables that are
> part of an extension. Is that normal?
> Attac
On Mon, Feb 16, 2015 at 4:45 PM, Michael Paquier
wrote:
> but not dumping any tables that are part of ext_member.
>
Excuse the typo => s/but/by/.
--
Michael
12 matches
Mail list logo
