Re: Initialization of ResultTupleSlot in AppendNode

> That also holds the plan's output tuple descriptor. If you tried to
> remove it, I think the ExecAssignResultTypeFromTL call would crash.
> And if you removed *that*, upper nodes would get unhappy, cf
> ExecGetResultType.
Yes, this is true. However upper nodes doesn't need in all cases, so is it
possible that ExecGetResultType should check if ResultTupleSlot is NULL,
then does functionality similar to ExecAssignResultTypeFromTL, to return
tuple descriptor.
This can save everytime allocation of ResultTupleSlot for AppendNode.

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Friday, September 16, 2011 4:24 AM
To: Amit Kapila
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Initialization of ResultTupleSlot in AppendNode

Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> I observed that during initialization of planstate for Append Node, we
> allocate ResulttupleSlot, however it is used only to send NULL slot
indicate
> no more tuples.

> Is it right or there is any other purpose of it?

That also holds the plan's output tuple descriptor. If you tried to
remove it, I think the ExecAssignResultTypeFromTL call would crash.
And if you removed *that*, upper nodes would get unhappy, cf
ExecGetResultType.

The use as an end-of-scan signal seems a bit vestigial, since we
could just as well return NULL, but it doesn't really cost enough
to be worth changing ...

regards, tom lane