> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
> Sent: 11 March 2003 15:55
> To: Dave Page
> Cc: pgman@candle.pha.pa.us; pgsql-hackers@postgresql.org; 
> pgsql-interfaces@postgresql.org
> Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign 
> 
> 
> I'd prefer to stick with rel OID and attnum; those are the 
> keys you are going to need for looking in the system 
> catalogs, anyway, and they're surely a lot more compact to 
> transmit than three Names (potentially 180 bytes or so).

OK.

> So let me get this straight: we want the attribute ID 
> information for any SELECT output column that is a simple Var 
> (no expressions, and no aggregated cases either), treating 
> view output columns as Vars belonging to the view.  

Yes. We could include attrelid for aggregates I suppose, but obviously
not attnum. Nothing at all for expressions of course.

> What about:
> 
> * Joins.  Does an aliased JOIN output variable get resolved 
> to the underlying table variable?  What about common columns 
> in USING/NATURAL joins?

Sorry, not sure what you mean - can you give me an example? 

> * Sub-selects.  Are you expecting
> 	SELECT x FROM (SELECT x FROM foo) ss
> to produce a reference to foo.x?  (If so, why is this 
> different from the case where ss is a view?)

Yes, I would expect that reference. I don't think it's different from a
view - we are trying to deciper the SQL itself, not what a view actually
represents so I would expect to see references to whatever relation is
in the original SQL, whether that relation is the result of a subselect
from another table/view, or a view. 

Regards, Dave.
Tue, 11 Mar 2003 17:26:48 -0000
"Dave Page" <dpage@vale-housing.co.uk>
Re: Roadmap for FE/BE protocol redesign 
"Dave Page" <dpage@vale-housing.co.uk> writes:
>> What about:
>> 
>> * Joins.  Does an aliased JOIN output variable get resolved 
>> to the underlying table variable?  What about common columns 
>> in USING/NATURAL joins?

> Sorry, not sure what you mean - can you give me an example? 

Sure, consider table1 with columns a,b,c and table2 with a,x,y:

	SELECT * FROM table1 NATURAL JOIN table2

has output columns a,b,c,x,y (notice only one column a).  How do you
expect these to be labeled?  Does the answer change if the join is
OUTER?  For example, in a LEFT JOIN x and y might return NULLs that
have nothing to do with any table2 row; is it still appropriate to
label them as table2 outputs?  And what do we do with column a in
each outer-join case?

Also, how about an aliased join

	SELECT * FROM (table1 NATURAL JOIN table2) AS q(r,s,t,u,v)

In this case the output columns are named q.r, q.s, q.t, q.u, q.v as
far as the SELECT list can tell --- it's actually illegal to refer to
table1.* or table2.* in the SELECT list, IIRC.  Do we drill down into
the JOIN?  (Probably so, if you expect the thing to drill down into
sub-SELECTs, but I want clarity ...)

>> * Sub-selects.  Are you expecting
>> SELECT x FROM (SELECT x FROM foo) ss
>> to produce a reference to foo.x?  (If so, why is this 
>> different from the case where ss is a view?)

> Yes, I would expect that reference. I don't think it's different from a
> view - we are trying to deciper the SQL itself, not what a view actually
> represents so I would expect to see references to whatever relation is
> in the original SQL, whether that relation is the result of a subselect
> from another table/view, or a view. 

Okay, that clarifies the intent quite a bit.  So we need to do the labeling
processing before any view rewriting occurs.  That probably means
sticking the info into Resdom nodes during the parser, rather than
extracting it on-the-fly from the planned query.

			regards, tom lane

Tue, 11 Mar 2003 13:38:42 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Roadmap for FE/BE protocol redesign 