Re: TopPlan, again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Cc: Gavin Sherry <swm(at)alcove(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TopPlan, again
Date: 2007-02-19 03:28:49
Message-ID: 3819.1171855729@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
> Gavin Sherry wrote:
>> On Sun, 18 Feb 2007, Tom Lane wrote:
>>> Comments, objections? Also, any thoughts about the names to use for
>>> these new node types? As I commented last year, I'm not completely
>>> happy with "TopPlan" because it won't actually be a subtype of Plan,
>>> but I don't have a better idea. Also I'm unsure what to call the
>>> cut-down RangeTblEntry struct; maybe RunTimeRangeTblEntry?
>>
>> I think TopPlan is misleading. What about MetaPlan instead of TopPlan? I
>> think RunTimeRangeTblEntry is okay, though long. ExecRangeTblEntry?

> Would ExecPlan be better? - matches ExecRangeTblEntry.

Neither of these seem to answer my worry that the node isn't a
subtype of "Plan".

One thought is that in some contexts this node type will probably appear
in lists that might also contain utility statement nodes. (Currently,
we represent such lists as Query lists that might or might not have
utilityStmt set, but I don't want a utilityStmt field in this node
type.) So maybe we should pick something based off "statement".
Perhaps "PlannedStmt" or "ExecutableStmt"?

ExecRangeTblEntry sounds good to me for the other thing.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-02-19 03:47:35 Re: TopPlan, again
Previous Message Mark Kirkwood 2007-02-19 03:02:23 Re: TopPlan, again