Re: Roadmap for FE/BE protocol redesign

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>, <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: Roadmap for FE/BE protocol redesign
Date: 2003-03-11 17:26:48
Message-ID: 03AF4E498C591348A42FC93DEA9661B8259D78@mail.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 11 March 2003 15:55
> To: Dave Page
> Cc: pgman(at)candle(dot)pha(dot)pa(dot)us; pgsql-hackers(at)postgresql(dot)org;
> pgsql-interfaces(at)postgresql(dot)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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Partho Bhowmick 2003-03-11 17:31:54 Largest filesize under Linux
Previous Message Bruce Momjian 2003-03-11 17:19:49 Still catching up

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2003-03-11 18:38:42 Re: Roadmap for FE/BE protocol redesign
Previous Message george young 2003-03-11 17:16:44 listen/notify with python pgdb