Re: Convert query plan to sql query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: mariem <mariem(dot)benfadhel(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert query plan to sql query
Date: 2014-11-08 16:43:37
Message-ID: 21193.1415465017@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Nov 8, 2014 at 1:09 AM, mariem <mariem(dot)benfadhel(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-08 16:52:43 Re: Add CREATE support to event triggers
Previous Message Tom Lane 2014-11-08 16:24:39 Re: row_to_json bug with index only scans: empty keys!