Robert Haas <robertmh...@gmail.com> writes:
> On Sat, Nov 8, 2014 at 1:09 AM, mariem <mariem.benfad...@gmail.com> wrote:
>> I'm aware of ruleutils.c which I think is a good tool but I don't think it's
>> appropriate as it takes the parse tree as input.
> "Parse", "Rewrite", and "Plan" are distinct stages. ruleutils.c takes
> the tree that results from rewriting, before planning has been done.
> So I'm not sure it's quite accurate to say that it takes the "parse
> tree" - rewrite rules will already have been applied.
More specifically: rewrite is a parsetree-to-parsetree transformation;
it does not change the representational rules at all. It's true that
the "typical" use of ruleutils is on parser output (ie stored views)
but it will work fine on rewriter output.
If what you're wishing for is that you could also capture the effects
of planner steps that are in the nature of source-to-source
transformations, I think that's going to be harder because no great
effort has been made to keep those at arm's length from steps that
don't have results describable as pure SQL. However, you could probably
get pretty far if you applied ruleutils.c to the modified parse tree
after the constant-folding and join tree simplification phases.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
