Skip site navigation (1) Skip section navigation (2)

Re: RangeTblEntry modifications

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Pilosov <alex(at)pilosoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: RangeTblEntry modifications
Date: 2001-06-30 22:49:19
Message-ID: 9839.993941359@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alex Pilosov <alex(at)pilosoft(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Alex PilosovDate: 2001-06-30 23:29:19
Subject: Re: RangeTblEntry modifications
Previous:From: Tom LaneDate: 2001-06-30 21:54:51
Subject: Another regression test fails to stand the test of time

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group