Robert Haas <robertmh...@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