Robert Haas <robertmhaas@gmail.com> writes:
> You should redesign this whole representation so that you just pass
> the whole query through to the optimizer without any structural
> change. Just as we do for other statements, you need to do the basic
> transformation stuff like looking up relation OIDs: that has to do
> with what the query MEANS and the external SQL objects on which it
> DEPENDS; those things have to be figured out before planning so that
> things like the plan-cache work correctly. But also just as we do for
> other statements, you should avoid having any code in this function
> that has to do with the way in which the MERGE should ultimately be
> executed, and you should not have any code here that builds a new
> query or does heavy restructuring of the parse tree.
Just to comment on that: IMV, the primary task of parse analysis is
exactly to figure out which database objects the query references or
depends on. We must know that much so that we can store proper
dependency information if the query goes into a view or rule. But as
soon as you add more processing than that, you are going to run into
problems of at least two kinds:
* The further the parsetree diverges from just representing what was
entered, the harder the task of ruleutils.c to reconstruct something
that looks like what was entered.
* The more information you absorb about the referenced objects, the
more likely it is that a stored view/rule will be broken by subsequent
ALTER commands. This connects to Robert's complaint about the parse
transformation depending on CTID, though I don't think it's quite the
same thing. We want to minimize the dependency surface of stored
rules -- for example, it's okay for a stored view to depend on the
signature (argument and return data types) of a function, but not
for it to depend on, say, the provolatile property. If we allowed
that then we'd have to forbid ALTER FUNCTION from changing the
volatility. I've not looked at this patch closely enough to know
whether it moves the goalposts in terms of what a dependency-on-a-
table means, but judging from Robert's and Andres' reviews, I'm
quite worried that it does.
Delaying transformations to the rewrite or plan phases avoids these
problems because now you are past the point where the query could
be stored to or fetched from a rule.
regards, tom lane
