Re: Proposal: CREATE CONVERSION

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

In response to

Responses

Browse pgsql-hackers by date

  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