From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | pgman(at)candle(dot)pha(dot)pa(dot)us |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, sszabo(at)megazone23(dot)bigpanda(dot)com, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: OCTET_LENGTH is wrong |
Date: | 2001-11-19 06:48:43 |
Message-ID: | 20011119154843U.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > What about encoding?
>
> Single-byte encodings have the same character and byte lengths. Only
> multi-byte encodings are different, right?
>
> In thinking about it, I think the function is called octet_length()
> to emphasize is returns the length in octets (bytes) rather than the
> length in characters.
I think Tom's point is whether octet_length() should regard input text
being encoded in the client side encoding or not.
My vote is octet_length() assumes database encodeding.
If you need client side encoded text length, you could do something
like:
select octet_length(convert('foo',pg_client_encoding()));
Note that there was a nasty bug in convert() which prevents above
working. I have committed fixes.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Alessio Bragadini | 2001-11-19 07:51:22 | Re: Open items |
Previous Message | Tom Lane | 2001-11-19 04:37:11 | format_type infelicity |