Re: Roadmap for FE/BE protocol redesign

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 11 March 2003 15:06
> 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
>
>
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)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.