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
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 |