From 99777b4bc94d2cfc6be8ae1dce624e46beefad08 Mon Sep 17 00:00:00 2001
From: beifangxiuwhx <kindaichweng@gmail.com>
Date: Thu, 13 Oct 2022 10:47:56 +0800
Subject: [PATCH] =?UTF-8?q?OB-FIX=20UP#001:=20=E4=BF=AE=E5=A4=8DBinary?=
 =?UTF-8?q?=E7=B1=BB=E5=9E=8B=E7=9A=84=E6=95=B0=E6=8D=AE=E6=A0=A1=E9=AA=8C?=
 =?UTF-8?q?=E5=AD=97=E7=AC=A6=E9=9B=86=E7=9A=84=E9=97=AE=E9=A2=98=20(#1086?=
 =?UTF-8?q?)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Description:
============

对于Binary类型来说，所有数据的存储看作二进制，是不需要校验字符集的。

但是OB在处理Binary类型的数据操作时，会校验字符集，举个例子，如果你在utf8mb4的表里，往binary写入GBK编码的"你"字，是会报错的。只能以 insert into t values(X'C4E3')方法插入

这对业务从mysql迁移到OB是很痛苦的事情。

Analysis:
=========

OB的binary类型底层实现和varchar相同，只在DDL阶段会区分binary类型。

出错的原因是在SQL解析阶段（transform_tree）将binary的字段按varchar处理进行字符集编码检查。这是因为在词法语法解析时数据库无从得知当前的字符串是否为binary（目前SQL解析阶段还获取不到实际表结构）

Fix:
========
修复方法：

个人觉得词法语法解析阶段进行字符集检查完全没有必要，后续物理执行计划算子打开时，OB也会对字符集编码进行处理。

因此，建议删除resolve_const函数中的check_well_formed_str

目前来看，这个函数只用来处理SQL解析后的parseNode节点，对后续的SQL逻辑没有侵入。

-------------

wenghaixing@unionpay.com