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