"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> This is the key point (say this is point_1) - we must make sure how deep we
> have to go to check validity.
The recorded plan has to somehow mention all the inlined functions that
were expanded out of existence. There might be several levels of such
things, but as long as we remember them all for invalidation purposes,
I don't see a problem.
A related example: an operator might point to an inline-able function.
Neither the operator nor the function will appear explicitly in the
finished plan tree, but they'd better both be listed in the side list
of invalidation dependencies.
> I don't quite understand the difference between a SQL function and a
> PL/PgSQL function here -
The planner doesn't know anything about inlining plpgsql functions.
So while the function might have its own invalidation issues to deal
with internally, a plan that calls it cannot need invalidation because
of that.
Obviously these issues depend a lot on the internal behavior of the
planner, so we are going to have to fix the planner to record the
identity of every object that it looks at without explicitly mentioning
it in the final plan. No other part of the system can be expected
to track all that.
regards, tom lane