> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 11 March 2003 18:39
> 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
>
>
> "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?
Oh, I see. Well, we cannot resolve those cases unless we decide in
advance that we will return metadata from either the left or right
table. That sings future FAQ to me so I would be inclined to omit the
additional info as we would for an aggregate.
> 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 ...)
Likewise, if we can't figure out the info accurately, simply don't
report it.
In these, and any other similar cases, we will be no worse off with no
underlying attribute data than we are now, and in the vast majority of
cases we will benefit.
Regards, Dave.