Re: index on function confuses drop table cascade on child

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: index on function confuses drop table cascade on child
Date: 2010-11-02 14:29:40
Message-ID: 4CCFDA0402000025000370DD@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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_walker is expecting --- in essence, since
> we're fabricating a single-element rtable for
> find_expr_references_walker to work with, we should fabricate the
> implied whole-table dependency entry too. But that seems a bit
> weird too, and in particular it's not obvious whether to do that
> if in fact the expression is empty, or doesn't contain any Var at
> all.

This one seems sensible *if* you assume that by the time it is
called there is a known dependency on the particular relation -- for
example, you are dealing with an index on that relation. Is that a
reasonable restriction on the use of the
recordDependencyOnSingleRelExpr function? If this was done, would
it allow simplification of the index_create code you showed in #1?

-Kevin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2010-11-02 14:39:26 Fwd: ***SPAM*** Re: BUG #5739: postgresql will not start
Previous Message Dimitri Fontaine 2010-11-02 13:46:27 Re: index on function confuses drop table cascade on child