Re: Roadmap for FE/BE protocol redesign

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, ZeugswetterA(at)spardat(dot)at, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Roadmap for FE/BE protocol redesign
Date: 2003-03-13 23:58:01
Message-ID: 3E711B09.3D81D7DE@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

Tom Lane wrote:
>
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2003-03-14 00:06:44 Re: SQL99 ARRAY support proposal
Previous Message Tom Lane 2003-03-13 22:40:35 Re: Roadmap for FE/BE protocol redesign

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2003-03-14 00:11:23 Re: Roadmap for FE/BE protocol redesign
Previous Message Tom Lane 2003-03-13 22:40:35 Re: Roadmap for FE/BE protocol redesign