Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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,

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?



pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group