Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

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-LynneDate: 2001-07-03 01:37:33
Subject: RE: Re: New data type: uniqueidentifier
Previous:From: John MooreDate: 2001-07-02 22:23:43
Subject: Re: Production Backup and Recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group