Re: Roadmap for FE/BE protocol redesign

> -----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.