What would AggrefExprState nodes' args contain?

From: Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: What would AggrefExprState nodes' args contain?
Date: 2011-04-26 06:34:20
Message-ID: BANLkTi=bZ93oj5iq5YS1Qf77cL68mwbmsg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello all,

While examining the executor, I was wondering what the *args part of
AggrefExprState nodes contain. I found that the Aggref (Expr)'s args list
is a list of TargetEntry nodes. But the state node's args is initialized in
ExecInitExpr as:

astate->args = (List *) ExecInitExpr((Expr *) aggref->args,
parent);

This would mean that the args is actually a ExprState node list with one
single item (the ExprState node / tree). I believe it potentially contains
the execution tree to determine the state / value of the aggref
(sub)expression. But then in the ExecEvalAggref function I do not see the
args coming into picture at all! I am also unable to find a call to some
function for executing the state node created in the args list. Also, no
value is being extracted from that node! Why is it so?

For quick reference I am adding the function (may be you don't need it but
still... its a small one):

/* ----------------------------------------------------------------
* ExecEvalAggref
*
* Returns a Datum whose value is the value of the precomputed
* aggregate found in the given expression context.
* ----------------------------------------------------------------
*/
static Datum
ExecEvalAggref(AggrefExprState *aggref, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone)
{
if (isDone)
*isDone = ExprSingleResult;

if (econtext->ecxt_aggvalues == NULL) /* safety check */
elog(ERROR, "no aggregates in this expression context");

*isNull = econtext->ecxt_aggnulls[aggref->aggno];
return econtext->ecxt_aggvalues[aggref->aggno];
}

What is the use of args in AggrefExprState node here? Is it there just for
some historical reason?

Regards,
Vaibhav

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Prakash Itnal 2011-04-26 06:45:46 Possible deadlock issue when one transaction waiting on other and vice versa? Should, ideally, postgres recognize blocking situation?
Previous Message Tom Lane 2011-04-26 04:11:29 Re: branching for 9.2devel