Re: Missing dependency tracking for TableFunc nodes

On 2019-11-12 15:32:14 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2019-11-12 10:19:30 -0500, Tom Lane wrote:
> >> I could imagine annotations that say "this field contains a function OID"
> >> or "this list contains collation OIDs" and then the find_expr_references
> >> logic could be derived from that.
>
> > I want to attach some annotations to types, rather than fields. I
> > e.g. introduced a Location typedef, annotated as being ignored for
> > equality purposes, instead of annotating each 'int location'. Wonder if
> > we should also do something like that for your hypothetical "function
> > OID" etc. above - seems like it also might give the human reader of code
> > a hint.
>
> Hm. We could certainly do "typedef FunctionOid Oid;",
> "typedef CollationOidList List;" etc, but I think it'd get pretty
> tedious pretty quickly --- just for this one purpose, you'd need
> a couple of typedefs for every system catalog that contains
> query-referenceable OIDs. Maybe that's better than comment-style
> annotations, but I'm not convinced.

I'm not saying that we should exclusively do so, just that it's
worthwhile for a few frequent cases.

> One issue there that I'm not sure how to resolve with autogenerated
> code, much less automated checking, is that quite a few cases in
> find_expr_references know that we don't need to record a dependency on
> an OID stored in the node because there's an indirect dependency on
> something else. For example, in FuncExpr we needn't log
> funcresulttype because the funcid is enough dependency, and we needn't
> log either funccollid or inputcollid because those are derived from
> the input expressions or the function result type. (And giving up
> those optimizations would be pretty costly, 4x more dependency checks
> in this example alone.)

Yea, that one is hard. I suspect the best way to address that is to have
explicit code for a few cases that are worth optimizing (like
e.g. FuncExpr), and for the rest use the generic logic using. I'd so
far just written the specialized cases into the "generated metadata"
using code - but we also could have an annotation that instructs to
instead call some function, but I doubt that's worthwhile.

> For sure I don't want both "CollationOid" and "RedundantCollationOid"
> typedefs

Indeed.

> so it seems like annotation is the solution for this

I'm not even sure annotations are going to be the easiest way to
implement some of the more complicated edge cases. Might be easier to
just open-code those, and fall back to generic logic for the rest. We'll
have to see, I think.

Greetings,

Andres Freund