RangeTblEntry modifications

With addition of Portal as RangeTblEntry, we'll have three very distinct
kinds of RTEs: Relation, Subquery and Portal.

They share some fields, but there are specific fields for each kind.

To encapsulate that (save on storage and gain cleanness), there are two
options:

1) Create three kinds of RTE, RangeTblEntryRelation, RangeTblEntryPortal
which will have these type fields. Then, code that wants to access
specific fields, will need to cast RTE to specific RTE type for access to
the fields.  Code would look like

RangeTblEntry *rte; 
Assert(e->rkind == RTE_RELATION);
(RangeTblEntryRelation rte)->relname

2) Keep one type, but unionize the fields. RTE definition would be:

typedef struct RangeTblEntry
{   NodeTag     type;   RTEType     rtype;
   /*    * 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
thisuser
 
*/   union {       struct {           /* Fields valid for a plain relation RTE (else NULL/zero): */           char
*relname;        /* real name of the relation */           Oid         relid;          /* OID of the relation */
}rel;          struct {           /* Fields valid for a subquery RTE (else NULL) */           Query      *subquery;
 /* the sub-query */       } sq;
 
       struct {           /* Fields valid for function-as portal RTE */           char       *portal;
TupleDesc tupleDesc;       } func;  } un;
 
}


And access would be: 

RangeTblEntry *rte; 
Assert(e->rkind == RTE_RELATION);
rte->un.rel.relname

I'm not sure which method is less ugly. I'm leaning towards 2).
But now I think that I'm always leaning in wrong direction :)


-alex