Re: Roadmap for FE/BE protocol redesign
| От | Dave Page |
|---|---|
| Тема | Re: Roadmap for FE/BE protocol redesign |
| Дата | |
| Msg-id | 03AF4E498C591348A42FC93DEA9661B8259D7B@mail.vale-housing.co.uk обсуждение исходный текст |
| Ответ на | Roadmap for FE/BE protocol redesign (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
> -----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.
В списке pgsql-hackers по дате отправления: