Re: [BUGS] index on function confuses drop table cascade on child

2010-11-02 Thread Tom Lane
"Kevin Grittner" writes: > Tom Lane wrote: >> 3. Or, perhaps we could change recordDependencyOnSingleRelExpr so >> that it generates a whole-table dependency on the target relation >> even if there are no Vars in the expression. This would make it >> act much more like the regular-query context

Re: [BUGS] index on function confuses drop table cascade on child

2010-11-02 Thread Kevin Grittner
Tom Lane wrote: > 3. Or, perhaps we could change recordDependencyOnSingleRelExpr so > that it generates a whole-table dependency on the target relation > even if there are no Vars in the expression. This would make it > act much more like the regular-query context that > find_expr_references_wa

Re: [BUGS] index on function confuses drop table cascade on child

2010-11-02 Thread Dimitri Fontaine
Tom Lane writes: > Any thoughts out there? Color me slow, but I don't understand what allows an index creation on a table to not systematically add a dependency entry for the index that references the table. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formatio

Re: [BUGS] index on function confuses drop table cascade on child

2010-11-01 Thread Tom Lane
I wrote: > "Kevin Grittner" writes: >> create index t_sname on t (sname(t)); > Huh, interesting. The reason the DROP misbehaves is that the index > doesn't have any dependency at all on table "t". Which appears to > be exposing the folly of this bit in find_expr_references_walker: > /*

Re: [BUGS] index on function confuses drop table cascade on child

2010-11-01 Thread Tom Lane
"Kevin Grittner" writes: > create index t_sname on t (sname(t)); Huh, interesting. The reason the DROP misbehaves is that the index doesn't have any dependency at all on table "t". Which appears to be exposing the folly of this bit in find_expr_references_walker: /* * A whole-