Bugs item #2822855, was opened at 2009-07-17 02:38 Message generated for change (Comment added) made by nielsnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2822855&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL/Core Group: SQL "stable" >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stefan de Konink (skinkie) Assigned to: Niels Nes (nielsnes) Summary: utf8 real size upon insert Initial Comment: ML quote: --- The second point is that my string is 99 characters long, and utf-8 with accented characters. So its length is less than 100 characters but more than 100 bytes. --- Since we already have an implementation of UTF8 checking in atoms/str.mx; we ought to use this one upon insert. Never the less I think that the proposed 'faster check' might give some benefit. http://www.daemonology.net/blog/2008-06-05-faster-utf8-strlen.html Test: create table utf8len(a varchar(1)); copy 1 records into utf8len from '/tmp/emptyaccount.utf8'; copy 1 records into utf8len from '/tmp/valueformoney.utf8'; insert into utf8len values ('€'); select a, length(a) AS len from utf8len; select 'Liever €uro' as "Liever euro"; drop table utf8len; emptyaccount.utf8: 0 valueformoney.utf8: € Excepted output: sql>create table utf8len(a varchar(1)); 0 tuples sql>copy 1 records into utf8len from '/tmp/emptyaccount.utf8'; Rows affected 1 sql>copy 1 records into utf8len from '/tmp/valueformoney.utf8'; Rows affected 1 sql>insert into utf8len values ('€'); Rows affected 1 sql>select a, length(a) AS len from utf8len; +---+-----+ | a | len | +===+=====+ | 0 | 1 | | € | 1 | | € | 1 | +---+-----+ 3 tuples sql>select 'Liever €uro' as "Liever euro"; +-------------+ | Liever euro | +=============+ | Liever €uro | +-------------+ 1 tuple sql>drop table utf8len; 0 tuples I have ran testing, 4 extra test came out differently. If someone could take a peak if the difference might be good, it would be helpful. ---------------------------------------------------------------------- >Comment By: Niels Nes (nielsnes) Date: 2009-07-20 18:41 Message: a test was added and the patch was applied. Thanks go to stefan for creating it. ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-07-17 15:29 Message: we agree that the current behaviour is weird we disagree that we should return a width of 4 for NULL-values, because a client needs not to render this "absent" value as the string "NULL". ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2009-07-17 15:25 Message: No it is undoubtably an error in the server observe: SELECT NULL; vs CREATE TABLE test (a int); INSERT INTO test VALUES (null); SELECT * FROM TEST; DROP TABLE test; sql>SELECT NULL; % . # table_name % single_value # name % char # type % 0 # length [ NULL ] sql>SELECT * FROM TEST; % sys.test # table_name % a # name % int # type % 1 # length [ NULL ] ---------------------------------------------------------------------- Comment By: Fabian (mr-meltdown) Date: 2009-07-17 15:17 Message: that feature is not correct it is a rendering issue of the client, that needs fixing there ---------------------------------------------------------------------- Comment By: Stefan de Konink (skinkie) Date: 2009-07-17 15:13 Message: The new patch fixes the issues related to bats or singular values that resulted in str_nil. The patch also improves the rendering (nifty feature). If NULL values are found the minimum column width will be made four. This means the column will never be too small and gets into 'odd vertical rendering'. This patch will break a lot of test or at least they should be allowed correct mostly 1 -> 4 changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2822855&group_id=56967 ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
