dbTalk Databases Forums  

behaviour of LENGTH() in postgresql v. 8

comp.databases.postgresql.novice comp.databases.postgresql.novice


Discuss behaviour of LENGTH() in postgresql v. 8 in the comp.databases.postgresql.novice forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Marcus Andree S. Magalhaes
 
Posts: n/a

Default behaviour of LENGTH() in postgresql v. 8 - 10-29-2004 , 05:10 PM







Dear all,

While checking the last Beta3-Beta4 Changelog of Postgres 8.0,
I saw the following:

* doc/TODO: Remove completed items:
<snip>
* -Make LENGTH() of
CHAR() not count trailing spaces

If I understand correctly, this will lead to the following situation:

CHAR_LENGTH('ABCD') == CHAR_LENGTH('ABCD ') == 4

This will definitely break some of our applications.

Just want to be sure if this LENGTH() behaviour _will_ appear
on the next version of Postgres. If true, can we somehow revert
to the current LENGTH() behaviour?

Can someone, please, clarify this issue?

Thanks a lot.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match


Reply With Quote
  #2  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: behaviour of LENGTH() in postgresql v. 8 - 10-29-2004 , 05:17 PM






Marcus Andree S. Magalhaes wrote:
Quote:
Dear all,

While checking the last Beta3-Beta4 Changelog of Postgres 8.0,
I saw the following:

* doc/TODO: Remove completed items:
snip
* -Make LENGTH() of
CHAR() not count trailing spaces

If I understand correctly, this will lead to the following situation:

CHAR_LENGTH('ABCD') == CHAR_LENGTH('ABCD ') == 4

This will definitely break some of our applications.

Just want to be sure if this LENGTH() behaviour _will_ appear
on the next version of Postgres. If true, can we somehow revert
to the current LENGTH() behaviour?

Can someone, please, clarify this issue?
You should review the release notes. The full description is:

* Make length() disregard trailing spaces in CHAR(n) (Gavin)
This change was made to improve consistency: trailing spaces
are semantically insignificant in CHAR(n) data, so
they should not be counted by length().

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html



Reply With Quote
  #3  
Old   
Tom Lane
 
Posts: n/a

Default Re: behaviour of LENGTH() in postgresql v. 8 - 10-29-2004 , 05:31 PM



"Marcus Andree S. Magalhaes" <marcus.magalhaes (AT) vlinfo (DOT) com.br> writes:
Quote:
If I understand correctly, this will lead to the following situation:
CHAR_LENGTH('ABCD') == CHAR_LENGTH('ABCD ') == 4
This will definitely break some of our applications.
If you think trailing spaces are semantically significant, you should be
using varchar or text fields to store them. In CHAR(n) fields they are
not significant, and we're doing our best to make that interpretation
consistent across all operations.

Just for the record, I get this with CVS tip:

regression=# select CHAR_LENGTH('ABCD ');
char_length
-------------
8
(1 row)

regression=# select CHAR_LENGTH('ABCD '::text);
char_length
-------------
8
(1 row)

regression=# select CHAR_LENGTH('ABCD '::varchar);
char_length
-------------
8
(1 row)

regression=# select CHAR_LENGTH('ABCD '::char(8));
char_length
-------------
4
(1 row)

(the first and second cases are in fact the same)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Reply With Quote
  #4  
Old   
Marcus Andree S. Magalhaes
 
Posts: n/a

Default Re: behaviour of LENGTH() in postgresql v. 8 - 10-29-2004 , 05:41 PM





Thanks for your answer. We're already using text and varchar, so we
should be safe when we migrate our server.

<snip>
Quote:
If you think trailing spaces are semantically significant, you should be
using varchar or text fields to store them. In CHAR(n) fields they are
not significant, and we're doing our best to make that interpretation
consistent across all operations.
snip

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.