Re: Proposal: CREATE CONVERSION - Mailing list pgsql-hackers

From Karel Zak
Subject Re: Proposal: CREATE CONVERSION
Date
Msg-id 20020711154138.J1895@zf.jcu.cz
Whole thread Raw
In response to Re: Proposal: CREATE CONVERSION  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Responses Re: Proposal: CREATE CONVERSION  (Tatsuo Ishii <t-ishii@sra.co.jp>)
List pgsql-hackers
On Thu, Jul 11, 2002 at 06:30:48PM +0900, Tatsuo Ishii wrote:
> > > No, it's not a libpq problem, but more common "client/server" problem
> > > IMO. It's very hard to share dynamically created object (info)
> > > effectively between client and server.
> > 
> >  IMHO dynamic object will keep server and client must ask for wanted 
> >  information to server.
> 
> I agree with you. However real problem is how fast it could be. For
> example, pg_mblen() is called for each word processed by libpq to know
> the byte length of the word. If each call to pg_mblen() accesses
> backend, the performance might be unacceptably slow.
It must load all relevant information about actual encoding(s) andcache it in libpq.
IMHO basic encoding information like name and id are not problem. The PQmblen() is big problem. Strange question: is
PQmblen()reallyneedful? I see it's used for result printing, but why backend notmark size of field (word) to result? If
backendgood knows size ofdata why not send this information to client togeter with data?   Karel
 

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: I am being interviewed by OReilly
Next
From: Tom Lane
Date:
Subject: Re: effective_cache_size