> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
> Sent: 11 March 2003 15:06
> 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 
> 
> 
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > Well, what would constitute a complete spec? I think I've told the 
> > group what I would like to be able to do, what unanswered questions 
> > can I (hopefully :-) ) answer?
> 
> I'm still unclear on exactly what your needs are.  In the 
> first place, are you expecting to obtain data from arbitrary 
> SELECT statements, or only from statements of the form 
> "SELECT * FROM single_table"?  

 From any statement that returns a resultset.

> You've also been confusing as 
> to whether you want transparency of views (ie, does a select 
> from a view return data about the view's nominal columns or 
> about the underlying base table columns?).  

The view's nominal columns. Resolving updates back to the base tables
will (hopefully) be the job of updateable views.

> What about cases 
> involving aggregates or grouping --- there may be simple Vars 
> in the target list, but they can hardly be thought to 
> represent updatable values.

Omit the information. That will tell the client that the data did not
come directly from an underlying relation.

> Also, you muttered something about inferring primary keys and 
> number of relations in query; seems like this feature isn't 
> solving your problem as far as that goes, because the set of 
> attributes visible in the target list isn't much help for either.

That one is my problem. If I can identify the source attributes as I
would like, then I can work out those details easily. For aggregates,
functions, expressions etc. non-existant meta data will also tell me
what I need to know. The attributes in the target list do help with
this, because if I know I have a complete primary key, then I know I can
build an update query for any given row.

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.

Regards, Dave.
Tue, 11 Mar 2003 15:34:34 -0000
"Dave Page" <dpage@vale-housing.co.uk>
Re: Roadmap for FE/BE protocol redesign 
"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

Tue, 11 Mar 2003 10:54:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Roadmap for FE/BE protocol redesign 