From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Ryan Kelly <rpkelly22(at)gmail(dot)com>, joe <joe(at)tanga(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key |
Date: | 2012-06-19 21:37:34 |
Message-ID: | 22882.1340141854@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Ryan Kelly's message of mar jun 19 16:20:58 -0400 2012:
>> On Tue, Jun 19, 2012 at 07:49:20PM +0000, joe(at)tanga(dot)com wrote:
>>> SELECT channels.id, channels.start_at, channels.end_at, channels.title
>>> FROM channels
>>> LEFT JOIN channels_products cp ON cp.channel_id = channels.id
>>> LEFT JOIN buyable_products bp ON bp.id = cp.product_id
>>> GROUP BY channels.id;
> The reason this doesn't work is that the primary key is not defined
> until later in the restore process.
> I think the fix is to make the view dependant on the primary key in the
> dump file.
Hmm ... check_functional_grouping does add the PK's OID to the query's
constraintDeps list. Apparently we're losing that dependency knowledge
somewhere between the parser and pg_dump?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-06-20 01:26:35 | Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key |
Previous Message | Alvaro Herrera | 2012-06-19 20:57:53 | Re: BUG #6699: pg_restore with -j -- doesn't restore view that groups by primary key |