I wrote:
>>> We could possibly hack something for the special case of rules, but
>>> I don't think this would be the last time we hear about this type of
>>> issue.
BTW, after comparing the dependencies emitted by this patch to those of
HEAD for the regression database, I am convinced that indeed
I wrote:
>> We could possibly hack something for the special case of rules, but
>> I don't think this would be the last time we hear about this type of
>> issue. I'm inclined to think that the best solution would be to add
>> generic logic to pg_dump that "looks through" any dependency references
I wrote:
> 168; 1259 41968 TABLE public t1 postgres
> ; depends on: 5
> 1921; 2606 41975 CONSTRAINT public t1_pkey postgres
> ; depends on: 168 168
> 169; 1259 41976 VIEW public v1 postgres
> ; depends on: 1919 5
> 1922; 0 41968 TABLE DATA public t1 postgres
> ; depends on:
I wrote:
> We could possibly hack something for the special case of rules, but
> I don't think this would be the last time we hear about this type of
> issue. I'm inclined to think that the best solution would be to add
> generic logic to pg_dump that "looks through" any dependency references
> to
I wrote:
> 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?
I looked into this a bit. The dependency does exist in pg_depend, but
it is shown as a dependency
Alvaro Herrera 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 +, j...@tanga.com wrote:
>>> SELECT channels.id, channels.start_at, channels.end_at, channels.title
>>> FROM channels
>>> LEFT JOIN channels_products cp ON cp.ch
Excerpts from Ryan Kelly's message of mar jun 19 16:20:58 -0400 2012:
> On Tue, Jun 19, 2012 at 07:49:20PM +, j...@tanga.com wrote:
> > View definition:
> > SELECT channels.id, channels.start_at, channels.end_at, channels.title
> >FROM channels
> >LEFT JOIN channels_products cp ON cp
On Tue, Jun 19, 2012 at 07:49:20PM +, j...@tanga.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6699
> Logged by: Joe Van Dyk
> Email address: j...@tanga.com
> PostgreSQL version: 9.1.4
> Operating system: OSX
> Description:
>
>
The following bug has been logged on the website:
Bug reference: 6699
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.1.4
Operating system: OSX
Description:
$ pg_restore -O -j 4 ~/tanga.dump -d tanga_dev_full_backup
pg_restore: [archiver (
