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 this user
*/

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