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
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
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...
regards, tom lane