I hope I'm not taking too much time from people here...
Here's where I'm now (and don't beat me too hard :)
I'm done with change of RangeTblEntry into three different node types:
have different fields. All the existing places instead of using
rte->subquery to determine type now use IsA(rte, RangeTblEntrySubSelect),
and later access fields after casting ((RangeTblEntrySubSelect *)rte)->xxx
Some functions that always work on Relation RTEs are declared to accept
RangeTblEntryRelation. Asserts are added everywhere before casting of RTE
into specific type. (Unless there was an IsA before, then I didn't put an
Let me know if that is an acceptable way of doing things, or casting makes
things too ugly. (I believe its the best way, unions are more dangerous
in this context).
Let me know if it would make sense to rename these types into
RTERelation,RTESubSelect,RTEPortal to cut down on their length ...
Now, I'm going to more interesting stuff, planner:
SELECT blah FROM CURSOR FOO, list_of_tables
This really should place CURSOR FOO at the very top of join list, since
(generally), you don't know what cursor is opened for, and you cannot
ReScan a portal.
I'm still trying to find out how to explain that to optimizer, but if
someone gives me a hint, I'd appreciate it.
Alternatively, we can store everything we retrieved from portal for future
ReScan purposes, but I really don't like this idea.
By the same token, I think, optimizer must reject queries of type:
"SELECT ... FROM CURSOR FOO, CURSOR BAR" because such thing will lead to a
nested loop scan, which is impossible because, again, you can't ReScan a
Let me know if I'm very off track with these assumptions, and if you have
to throw rocks at me, pick little ones ;)
pgsql-hackers by date
|Next:||From: Christopher Kings-Lynne||Date: 2001-07-03 01:37:33|
|Subject: RE: Re: New data type: uniqueidentifier|
|Previous:||From: John Moore||Date: 2001-07-02 22:23:43|
|Subject: Re: Production Backup and Recovery|