Re: [HACKERS] Roadmap for FE/BE protocol redesign - Mailing list pgsql-interfaces

From Hiroshi Inoue
Subject Re: [HACKERS] Roadmap for FE/BE protocol redesign
Date
Msg-id 3E711B09.3D81D7DE@tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] Roadmap for FE/BE protocol redesign  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Roadmap for FE/BE protocol redesign  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
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/


pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: Upgrading the backend's error-message infrastructure
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign