Paul,

> Now we get to the part that is hard to understand: what is the
> structure in the subclass types? The full list is:
>
> enum rsb_t
> {
> rsb_boolean, // predicate (logical condition)
> rsb_cross, // inner join as a nested loop
> rsb_first, // retrieve first n records
> rsb_skip, // skip n records
> rsb_indexed, // access via an index
> rsb_merge, // join via a sort merge
> rsb_sequential, // natural scan access
> rsb_sort, // sort
> rsb_union, // union
> rsb_aggregate, // aggregation
> rsb_ext_sequential, // external sequential access
> rsb_ext_indexed, // external indexed access
> rsb_ext_dbkey, // external DB_KEY access
> rsb_navigate, // navigational walk on an index
> rsb_left_cross, // left outer join as a nested loop
> rsb_procedure // stored procedure
> };
>
> So how could this list make sense?
> a. The most obvious option would be table types. Here we would
> have internal table, external table and procedure (add: cursor)
> b. The next option could be access types. Here we would have
> sequential, index and bitmap -- perhaps others
> c. A third option could be aggregation types, such join, union,
> sort, etc.

From the higher levels POV, RSB is a cursor. It can be opened, fetched and
closed. More precisely (from the implementation POV), RSB is a
transformation from one data stream to another. Lowest-level RSBs
(rsb_sequential, rsb_indexed, rsb_navigate) are plain access types.
rsb_boolean applies a filter to the input stream, rsb_skip removes first N
rows from a stream via N dummy fetches, rsb_join merges two streams into one
using the nested loops algorithm and so on. They are linked in a chain by
the optimizer to produce the wanted result. Their common parts are: (a) they
share the same public interface and (b) they have K ( 0 <= K < inf ) input
RSBs.

Hope Jim will explain it better ;-)


Dmitry