Skip site navigation (1) Skip section navigation (2)

Re: Roadmap for FE/BE protocol redesign

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
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 15:54:32
Message-ID: 5242.1047398072@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
"Dave Page" <dpage(at)vale-housing(dot)co(dot)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

In response to

pgsql-hackers by date

Next:From: Christoph HallerDate: 2003-03-11 16:04:31
Subject: Re: gmake -C regress check failure
Previous:From: Dave PageDate: 2003-03-11 15:34:34
Subject: Re: Roadmap for FE/BE protocol redesign

pgsql-interfaces by date

Next:From: george youngDate: 2003-03-11 17:16:44
Subject: listen/notify with python pgdb
Previous:From: Dave PageDate: 2003-03-11 15:34:34
Subject: Re: Roadmap for FE/BE protocol redesign

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group