From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | peter_e(at)gmx(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: CREATE CONVERSION |
Date: | 2002-07-11 13:41:38 |
Message-ID: | 20020711154138.J1895@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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) and
cache it in libpq.
IMHO basic encoding information like name and id are not problem.
The PQmblen() is big problem. Strange question: is PQmblen() really
needful? I see it's used for result printing, but why backend not
mark size of field (word) to result? If backend good knows size of
data why not send this information to client togeter with data?
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-07-11 14:06:36 | Re: workaround for lack of REPLACE() function |
Previous Message | Marc G. Fournier | 2002-07-11 13:24:21 | Re: I am being interviewed by OReilly |