selecting from cursor

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: selecting from cursor
Date: 2001-07-02 22:31:50
Message-ID: Pine.BSO.4.10.10106301524370.7004-100000@spider.pilosoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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:
RangeTblEntryRelation,RangeTblEntrySubSelect,RangeTblEntryPortal which
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
Assert).

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

Let me know if I'm very off track with these assumptions, and if you have
to throw rocks at me, pick little ones ;)

-alex

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2001-07-03 01:37:33 RE: Re: New data type: uniqueidentifier
Previous Message John Moore 2001-07-02 22:23:43 Re: Production Backup and Recovery