Re: explain.c: why trace PlanState and Plan trees separately? - Mailing list pgsql-hackers

From Yeb Havinga
Subject Re: explain.c: why trace PlanState and Plan trees separately?
Date
Msg-id 4C3C8463.4070506@gmail.com
Whole thread Raw
In response to Re: explain.c: why trace PlanState and Plan trees separately?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: explain.c: why trace PlanState and Plan trees separately?
List pgsql-hackers
Tom Lane wrote:
> Yeb Havinga <yebhavinga@gmail.com> writes:
>   
>> Tom Lane wrote:
>>     
>>> The reason I'm on about this at the moment is that I think I see how to
>>> get ruleutils to print PARAM_EXEC Params as the referenced expression
>>> rather than $N ...
>>>       
>> Wouldn't this obfuscate the plan more than printing subplan arguments at 
>> the call site?
>>     
>
> It would if subplans could have more than one call site, but they can't.
>
> I do intend to force qualification of Vars that are printed as a result
> of param expansion;
>   
Will the new referenced expression printing also be used when printing 
subplans?

If yes, I do not have to submit the latest version of a patch I made for 
subplan argument printing (discussed earlier in this thread 
http://archives.postgresql.org/pgsql-hackers/2010-02/msg01602.php)

regards,
Yeb Havinga



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: multibyte charater set in levenshtein function
Next
From: Dave Page
Date:
Subject: ERROR: argument to pg_get_expr() must come from system catalogs