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

"Dave Page" <dpage@vale-housing.co.uk> writes:
> No, but with them we can avoid cluttering the wire protocol with fields
> for all this, and the JDBC required data. With 2 numeric columns
> (attrelid, attnum), any application/interface can query the system
> catalogs easily for whatever extra info they like.

This is my feeling also.  We shouldn't try to guess in the protocol
exactly what set of information will be wanted by a frontend; we should
just provide the catalog keys needed to look up whatever is wanted.

I like attrelid/attnum because (a) it's compact --- not much added
overhead for apps that don't care; and (b) it's a primary key, which
names are not.  The relid/attnum identity of a column will remain the
same as long as it exists.  A name-based API breaks the moment some
other user renames things; similar objections could be raised against
attlognum, if we had it.

The point about apps breaking if the system catalog layout changes is a
fair one, but that situation would be no worse than it's ever been; ODBC
and JDBC have coped well enough so far.  In any case the best solution
would be to offer functions that hide the details of where to find any
given bit of info.  We've got a few like that already (format_type() for
example) and I have no problem with adding more.
        regards, tom lane

Tom Lane wrote:
> 
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > No, but with them we can avoid cluttering the wire protocol with fields
> > for all this, and the JDBC required data. With 2 numeric columns
> > (attrelid, attnum), any application/interface can query the system
> > catalogs easily for whatever extra info they like.
> 
> This is my feeling also.  We shouldn't try to guess in the protocol
> exactly what set of information will be wanted by a frontend; we should
> just provide the catalog keys needed to look up whatever is wanted.

Does looking up by the catalog keys take no cost ?

regards,
Hiroshi Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/

Dave Page wrote:
> 
> It's rumoured that Hiroshi Inoue once said:
> > Tom Lane wrote:
> >>
> >> "Dave Page" <dpage@vale-housing.co.uk> writes:
> >> > No, but with them we can avoid cluttering the wire protocol with
> >> > fields for all this, and the JDBC required data. With 2 numeric
> >> > columns (attrelid, attnum), any application/interface can query the
> >> > system catalogs easily for whatever extra info they like.
> >>
> >> This is my feeling also.  We shouldn't try to guess in the protocol
> >> exactly what set of information will be wanted by a frontend; we
> >> should just provide the catalog keys needed to look up whatever is
> >> wanted.
> >
> > Does looking up by the catalog keys take no cost ?
> 
> Obviously there is cost, but doing a lookup only on demand, has got to be
> cheaper in the long run than including the entire column definition in the
> message whether it's wanted or not?

So if there are 100 fields, should we ask the backend 
the column name 100 times ?

regards,
Hiroshi Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/

"Dave Page" <dpage@vale-housing.co.uk> writes:
> It's rumoured that Hiroshi Inoue once said:
>> Does looking up by the catalog keys take no cost ?

> Obviously there is cost, but doing a lookup only on demand, has got to be
> cheaper in the long run than including the entire column definition in the
> message whether it's wanted or not?

More to the point, the cost is paid by applications that want the
functionality, and not by those that don't.

It'd probably be reasonable for client libraries to maintain a cache
of column info, so that they only have to query the backend about a
particular column ID once per connection.  (This is one reason why
I want attrelid/attnum to be the info given on the wire: it's stable
enough to be used over a whole session to index such a cache.  Names
could not safely be used that way.)
        regards, tom lane

Tom Lane wrote:
> 
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > It's rumoured that Hiroshi Inoue once said:
> >> Does looking up by the catalog keys take no cost ?
> 
> > Obviously there is cost, but doing a lookup only on demand, has got to be
> > cheaper in the long run than including the entire column definition in the
> > message whether it's wanted or not?
> 
> More to the point, the cost is paid by applications that want the
> functionality, and not by those that don't.
> 
> It'd probably be reasonable for client libraries to maintain a cache
> of column info, so that they only have to query the backend about a
> particular column ID once per connection.

Is it a kind of thing that the server forces the clients
easily ?
Hmm as for PREPAREd statements, it seems much better to
implement functions which returns fields info for the
statement than relying on such a protocol level change.
regards,
Hiroshi Inouehttp://www.geocities.jp/inocchichichi/psqlodbc/

Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> Hmm as for PREPAREd statements, it seems much better to
> implement functions which returns fields info for the
> statement than relying on such a protocol level change.

Well, we're changing the protocol anyway for other purposes, so the
extra burden of a change here doesn't seem large.  I think it's more
useful to worry about what functionality we want than to worry about
whether it's changed...
        regards, tom lane