Re: selecting from cursor - Mailing list pgsql-hackers

On Mon, 2 Jul 2001, Tom Lane wrote:

> Alex Pilosov <alex@pilosoft.com> writes:
> > 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).
> 
> And what are you doing with the places that don't care which kind of RTE
> they are dealing with (which is most of them IIRC)?  While you haven't

They just have things declared as RangeTblEntry *, and as long as they
don't access type-specific fields, they are fine.

> shown us the proposed changes, I really suspect that a union would be
> cleaner, because it'd avoid ugliness in those places.  Bear in mind that
I have attached the diff of what I have now. Please take a look through
it. Its not exactly done (only the parser and pieces of executor parts of
"FROM CURSOR" are there, and I didn't attach gram.y diff because its just
too ugly now), so its definitely not ready for application, but with these
changes, it compiles and 'make check' goes through fine ;)

> the three RTE types that you have are going to become five or six real
> soon now, because I have other things to fix that need to be done that
> way --- so the notational advantage of a union is going to increase.
> 
> > ... you cannot ReScan a portal. 
> 
> That's gonna have to be fixed.  If you're not up for it, don't implement
> this.  Given that cursors (are supposed to) support FETCH BACKWARDS,
> I really don't see why they shouldn't be expected to handle ReScan...
I thought only scrollable cursors can do that. What if cursor isn't
scrollable? Should it error during the execution?

For scrollable cursors, Rescan should be implemented as 'scroll backwards
until you can't scroll no more', correct?

-alex