From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dave Page <dpage@vale-housing.co.uk>
Cc: pgman@candle.pha.pa.us
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
Date: Tue, 11 Mar 2003 10:54:32 -0500
Message-ID: <5242.1047398072@sss.pgh.pa.us> (raw)
In-Reply-To: <03AF4E498C591348A42FC93DEA9661B8259D6F@mail.vale-housing.co.uk>
References: <03AF4E498C591348A42FC93DEA9661B8259D6F@mail.vale-housing.co.uk>
"Dave Page" <dpage@vale-housing.co.uk> writes:
> As I see it, the tidy/simple answer is to add nspname, relname and
> attname information to each attribute in the row description, and if any
> one of those cannot be easily determined, or the value doesn't come
> directly from there (ie an aggregate), it is simply omitted or left
> empty. It could be done more efficiently with attnum/attrelid, but I
> wonder if that might cause problems in the future if attnum gets hacked
> about.
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).
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. What about:
* Joins. Does an aliased JOIN output variable get resolved to the
underlying table variable? What about common columns in USING/NATURAL
joins?
* 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?)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, dpage@vale-housing.co.uk, pgman@candle.pha.pa.us, pgsql-hackers@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
In-Reply-To: <5242.1047398072@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox