Alex Pilosov <alex@pilosoft.com> writes:
> 2) Keep one type, but unionize the fields. RTE definition would be:
> I'm not sure which method is less ugly. I'm leaning towards 2).
I like that better, also, mainly because it would force code updates
everyplace that the RTE-type-specific fields are accessed; less chance
of incorrect code getting overlooked that way.
Note that some of the comments would be obsolete, eg
> /* Fields valid for a plain relation RTE (else NULL/zero): */
They're not null/0 for a non-relation RTE, they're just not defined at
all.
> struct {
> /* Fields valid for function-as portal RTE */
> char *portal;
> TupleDesc tupleDesc;
> } func;
I'm not sure I buy this, however. You'll need an actual
RTE-as-function-call variant that has the function OID and compiled list
of arguments. Remember that the parsetree may live a lot longer than
any specific Portal. For a function call, we'll need to build the
Portal from the function-call-describing RTE at the start of execution,
not during parsing.
This point may also make "select from cursor" rather harder than it
appears at first glance. You may want to back off on that part for now.
regards, tom lane