Hello Sergei,
Please review a fix for MDEV-10306.
Thanks!
commit af8887b86ccbaea8782cf54fe445cf53aaef7c06
Author: Alexander Barkov
Date: Tue Feb 28 10:28:09 2017 +0400
MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT in subquery
The bug happens because of a
Hi, Alexander!
On Feb 28, Alexander Barkov wrote:
> commit af8887b86ccbaea8782cf54fe445cf53aaef7c06
> Author: Alexander Barkov
> Date: Tue Feb 28 10:28:09 2017 +0400
>
> MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT
> in subquery
>
> The bug happens bec
Hi!
Am 01.03.2017 um 13:56 schrieb Sergei Golubchik:
Hi, Alexander!
On Feb 28, Alexander Barkov wrote:
commit af8887b86ccbaea8782cf54fe445cf53aaef7c06
Author: Alexander Barkov
Date: Tue Feb 28 10:28:09 2017 +0400
MDEV-10306 Wrong results with combination of CONCAT, SUBSTR and CONVERT
Hi, Oleksandr!
On Mar 01, Oleksandr Byelkin wrote:
> >
> > So, I see few possible approaches to this and other similar queries:
> >
> > 1. We specify that no Item's val method can modify the buffer of the
> > arguments. That is, CONCAT will always have to copy. SUBSTR won't
> > need to cop
Am 01.03.2017 um 15:04 schrieb Sergei Golubchik:
Hi, Oleksandr!
On Mar 01, Oleksandr Byelkin wrote:
So, I see few possible approaches to this and other similar queries:
1. We specify that no Item's val method can modify the buffer of the
arguments. That is, CONCAT will always have to copy
Hi, Oleksandr!
On Mar 01, Oleksandr Byelkin wrote:
>
> Actually val_str accept buffer and if we ensure that the buffer used
> each time is different and value stored in it changing it is not a
> problem at all, problem is that some Items do not use it in sake of
> the efficiency, so maybe we shou
Hello,
On Wed, Mar 01, 2017 at 01:56:24PM +0100, Sergei Golubchik wrote:
> Hi, Alexander!
>
> On Feb 28, Alexander Barkov wrote:
>
> > commit af8887b86ccbaea8782cf54fe445cf53aaef7c06
> > Author: Alexander Barkov
> > Date: Tue Feb 28 10:28:09 2017 +0400
> >
> > MDEV-10306 Wrong results wi
Hello Serg and Sergey,
Serg, please review a new version of the patch.
Sergey, thanks for noticing the problem with a missing
res->is_alloced() part in the condition. This fixed the
original problem reported in the bug.
I also had to modify Item_func_conv_charset::val_str(),
to make this query
Hi, Sergey!
On Mar 02, Sergey Petrunia wrote:
>
> My take on the issue: I read the comment for Item::val_str:
>
> The caller of this method can modify returned string, but only in case
> when it was allocated on heap, (is_alloced() is true). This allows
>
Hi, Alexander!
On Mar 03, Alexander Barkov wrote:
> Hello Serg and Sergey,
>
> Serg, please review a new version of the patch.
>
>
> Sergey, thanks for noticing the problem with a missing
> res->is_alloced() part in the condition. This fixed the
> original problem reported in the bug.
>
> I al
Hello Sergei,
On 03/04/2017 12:12 AM, Sergei Golubchik wrote:
> Hi, Alexander!
>
> On Mar 03, Alexander Barkov wrote:
>> Hello Serg and Sergey,
>>
>> Serg, please review a new version of the patch.
>>
>>
>> Sergey, thanks for noticing the problem with a missing
>> res->is_alloced() part in the co
Hi, Alexander!
On Mar 06, Alexander Barkov wrote:
> >> @@ -3378,16 +3379,16 @@ String *Item_func_conv_charset::val_str(String
> >> *str)
> >>DBUG_ASSERT(fixed == 1);
> >>if (use_cached_value)
> >> return null_value ? 0 : &str_value;
> >> - String *arg= args[0]->val_str(str);
> >> +
Hello Sergei,
Thanks for your review. Here's a new version of the patch.
Please see comments below:
On 03/06/2017 10:50 AM, Sergei Golubchik wrote:
> Hi, Alexander!
>
> On Mar 06, Alexander Barkov wrote:
@@ -3378,16 +3379,16 @@ String *Item_func_conv_charset::val_str(String
*str)
Hi, Alexander!
On Jun 16, Alexander Barkov wrote:
>
> Agreed. This version fixes around 16 classes that had the same problem,
> and which only needed to swap "str" and "tmp_value" in their val_str()
> implementations.
>
> As agreed on slack, the following three classes:
> - Item_str_conv
> - Ite
14 matches
Mail list logo
