Обсуждение: Re: [HACKERS] Roadmap for FE/BE protocol redesign

"Dave Page" <dpage@vale-housing.co.uk> writes:
> What about the addition of pg_attribute.attrelid &
> pg_attribute.attname/attnum in RowDesription messages to identify the
> underlying attribute (where appropriate)?

Well, we can talk about it, but I still think that any frontend that
relies on such information is broken by design.  (And if that means the
JDBC spec is broken, then the JDBC spec is broken.)

Just to start with, if I do "SELECT * FROM view", am I going to see the
info associated with the view column, or with the hypothetical
underlying table column?  (Actually, didn't I already make a list of a
bunch of ways in which this concept is underspecified?  AFAIR, you
didn't suggest answers to any of those questions ... but we need answers
to all of them if we are going to implement the feature.)
        regards, tom lane

Tom Lane wrote:
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > What about the addition of pg_attribute.attrelid &
> > pg_attribute.attname/attnum in RowDesription messages to identify the
> > underlying attribute (where appropriate)?
> 
> Well, we can talk about it, but I still think that any frontend that
> relies on such information is broken by design.  (And if that means the
> JDBC spec is broken, then the JDBC spec is broken.)
> 
> Just to start with, if I do "SELECT * FROM view", am I going to see the
> info associated with the view column, or with the hypothetical
> underlying table column?  (Actually, didn't I already make a list of a
> bunch of ways in which this concept is underspecified?  AFAIR, you
> didn't suggest answers to any of those questions ... but we need answers
> to all of them if we are going to implement the feature.)

I was willing to add a hack to enable default column labels to be
"table.column" --- that seemed like the least obtrusive.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I was willing to add a hack to enable default column labels to be
> "table.column" --- that seemed like the least obtrusive.

Most of the definitional issues still apply: which table name are you
going to insert, and under what conditions?

If we're revising the protocol, there's no reason to hack up the column
label to carry two pieces of info; it'd be cleaner to provide a separate
slot in the T message to carry the table name.  I just want to see a
reasonably complete spec for what the feature is supposed to do, before
we buy into it ...
        regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I was willing to add a hack to enable default column labels to be
> > "table.column" --- that seemed like the least obtrusive.
> 
> Most of the definitional issues still apply: which table name are you
> going to insert, and under what conditions?
> 
> If we're revising the protocol, there's no reason to hack up the column
> label to carry two pieces of info; it'd be cleaner to provide a separate
> slot in the T message to carry the table name.  I just want to see a
> reasonably complete spec for what the feature is supposed to do, before
> we buy into it ...

I don't think we can get a complete spec, and hence the _hack_ idea.  :-)

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

"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"?  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?).  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.

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.
        regards, tom lane