Re: selecting from cursor

On Tue, 3 Jul 2001, Tom Lane wrote:

> Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> >> 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.
>
> So you have four (soon to be six or seven) different structs that *must*
> have the same fields? I don't think that's cleaner than a union ...
> at the very least, declare it as structs containing RangeTblEntry,
> similar to the way the various Plan node types work (see plannodes.h).
Please see my diffs. Its implemented via #define to declare all common
fields.

I.E.:
#define RTE_COMMON_FIELDS \
NodeTag type; \
/* \
* Fields valid in all RTEs: \
*/ \
Attr *alias; /* user-written alias clause, if any */ \
Attr *eref; /* expanded reference names */ \
bool inh; /* inheritance requested? */ \
bool inFromCl; /* present in FROM clause */ \
bool checkForRead; /* check rel for read access */ \
bool checkForWrite; /* check rel for write access */ \
Oid checkAsUser; /* if not zero, check access as this user
*/ \

typedef struct RangeTblEntry
{
RTE_COMMON_FIELDS
} RangeTblEntry;

typedef struct RangeTblEntryRelation
{
RTE_COMMON_FIELDS
/* Fields valid for a plain relation RTE */
char *relname; /* real name of the relation */
Oid relid; /* OID of the relation */
} RangeTblEntryRelation;

If RTEs are done the way plan nodes done, the syntax would be pretty much
the same, only with one more indirection to access common fields.

This is how code looks with my changes:
RangeTblEntry *rte=rt_fetch(..)

For common fields
rte->eref

For type-specific fields
((RangeTblEntryRelation *) rte)->relid

This is how it would look if it was done like Plan nodes are done:
RangeTblEntry *rte=rt_fetch(..)

For common fields:
rte->common->eref

For type-specific fields:
((RangeTblEntryRelation *)rte)->relid

> > For scrollable cursors, Rescan should be implemented as 'scroll backwards
> > until you can't scroll no more', correct?
>
> No, it should be implemented as Rescan. The portal mechanism needs to
> expose the Rescan call for the contained querytree.
Ok.