Message-ID: <3E711B09.3D81D7DE@tpf.co.jp>
Date: Fri, 14 Mar 2003 08:58:01 +0900
From: Hiroshi Inoue <Inoue@tpf.co.jp>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dave Page <dpage@vale-housing.co.uk>, ZeugswetterA@spardat.at,
	pgman@candle.pha.pa.us, pgsql-hackers@postgresql.org,
	pgsql-interfaces@postgresql.org
Subject: Re: Roadmap for FE/BE protocol redesign
References: <03AF4E498C591348A42FC93DEA9661B8259D8D@mail.vale-housing.co.uk>
	<27130.1047484194@sss.pgh.pa.us> <3E702552.DA8A29A9@tpf.co.jp>
	<50073.80.177.99.193.1047549156.squirrel@ssl.vale-housing.co.uk>
	<4860.1047568767@sss.pgh.pa.us>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

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 Inoue
	http://www.geocities.jp/inocchichichi/psqlodbc/