帰ってきた！ 標準はあるにはあるが癖の多いSQL #17 - 文字数取得関数も癖が強い
本エントリーは、
JPOUG Advent Calendar 2024
MySQL Advent Calendar 2024
PostgreSQL Advent Calendar 2024 の21目の記事です。
JPOUG Advent Calendar 2024の昨日のポストは、takashitel(おおの)さんの「RMANで表単位リカバリをする際の注意点（RMAN-06024）」、
MySQL Advent Calendar 2024の昨日のポストは、yoku0825さんの「Blackholeストレージエンジンとバイナリログと 2024」、
PostgreSQL Advent Calendar 2024の昨日のポストは、Noriyoshi Shinodaさんの「PostgreSQL と Oracle Database でシーケンスの動作を比較する」（シリーズ1）、および Shimooo_mutenkaさんの「【PostgreSQL】リストアの進捗状況を監視・表示するシェルスクリプト」（シリーズ2）
でした。
では、本題。
同じ名称の関数でも癖があるので移行するようなケースでは注意した方がいいよ！
という非互換はみなさんご存知の通りだと思います。
それでも検証漏れに気づいた時の雰囲気の悪さと言ったらなんとも言えませんよね。
その影響で、その他の非互換についても漏れているのでは？
と疑われてしまったり、玉突きでタスクが増えたり良いことはありません。
そんなことを一つでも減らしたいというネタです。:)
同じ結果を返す関数でも名称が違う程度ならまだ分かり易いですが、インプットする値による挙動の違いは把握するのが難しいですよね。
（マニュアルに書かれていたり書かれていなかったり、書かれていても気づきにくいところに書かれていたり、関数そのものの影響ではなかったり、様々な要因があります）
今日はそのような癖の一つで、文字数取得関数の癖。（すでに、前述した癖の一つに気づいちゃった方もいると思いますが、No Spoiler!でw）
今回のネタも有名なものの一つだと思いますが、あらためて、意識しておこう！
という意味も込めて取り上げてみました。（癖のあるシリーズでもまだ取り上げてなかったこともありますw）
長いのでw 最初に癖のまとめを。
文字数取得関数 ・Oracle Database
- LENGTH()
- NULLが渡された場合、 NULL が返される
- 空文字が渡された場合、 NULL が返される（Oracle Databaseが空文字をNULLとして扱うため）
- CHAR(n)全てが空白の文字列の場合、空白分の文字数が返る。CHAR(10 CHAR)の場合は、10.
- CHAR型の後続空白は文字数にカウントされる。e.g. CHAR(10 CHAR) <= 'ABC'の場合、右側を空白埋めして 10 が返される
参考）
Oracle Database / Release 19 / SQL言語リファレンス / LENGTH
今回の主役であるLENGTH()関数については以下のような記載があります。
Oracle Database / Release 19 / SQL Language Reference / Table C-1 Oracle Support of Core SQL Features
"E021-04, CHARACTER_LENGTH function: use LENGTH function instead" 上記、ドキュメントに記載されている通り、Oracle DatabaseのLENGTH()関数は方言なんですよね！！
早速、癖者感が強くなったところでw、次へ進みましょうwwww
・MySQL
- CHAR_LENGTH() / CHARACTER_LENGTH()
- NULLが渡された場合、 NULL が返される
- 空文字が渡された場合、0 が返される
- 全て空白の文字列の場合、 0 が返されさる（空白がトリムされるため）
- CHAR型の後続空白は文字数にカウントされない。（空白がトリムされるため）ただし、 CHAR_LENGTH(CAST('12345 ' AS CHAR(10)))、 CHAR_LENGTH(CAST('12345 ' AS CHAR(30)))のようなケースでは空白を含むリテラルの文字数が返る。(Release 8.0.36)
参考）
MySQL 8.0 リファレンスマニュアル / データ型 / 文字列データ型 / CHAR および VARCHAR 型
https://dev.mysql.com/doc/refman/8.0/ja/char.html
"CHARACTER_LENGTH() は CHAR_LENGTH() のシノニム。E021-04対応とのこと。標準対応ということですね。Oracle Databaseはやってないですけど" なお、 LENGTH( str ) は、Oracle Databaseだと LENGTHB( char ) 相当ですね。バイト数を返してくるので。まじか！ この類の関数の癖の多さと強さは半端ないですね。 有名な違いなので見落とされることはなさそうな気もしますが、注意が必要な部分です。
Oracle Database 以外で要注意なのはCHAR型の右側のスペースの扱いですね。該当関数云々というよりも。
"CHAR 値は格納されると、指定された長さになるように右側がスペースで埋められます。 PAD_CHAR_TO_FULL_LENGTH SQL モードが有効になっていないかぎり、CHAR 値が取り出されるときに、末尾のスペースが削除されます。"
MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / LENGTH(str) MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / CHAR_LENGTH(str) ”文字で測定された文字列 str の長さを返します。 マルチバイト文字は、単一の文字としてカウントされます。 つまり、5 つの 2 バイト文字を含む文字列では、LENGTH() は 10 を返し、CHAR_LENGTH() は 5 を返します。”
MySQL 8.0 リファレンスマニュアル / 関数と演算子 / 文字列関数および演算子 / CHARACTER_LENGTH(str)
・PostgreSQL
- CHAR_LENGTH() / CHARACTER_LENGTH() / LENGTH()
- NULLが渡された場合、 NULL が返される
- 空文字が渡された場合、0 が返される
- 全て空白の文字列の場合、 0 が返されさる（空白がトリムされるため）
- CHAR型の後続空白は文字数にカウントされない（空白がトリムされるため）
参考）
PostgreSQL 16.4文書 / 第9章 関数と演算子 / 9.4. 文字列関数と演算子
PostgreSQL 16.4文書 / D.1. サポートされている機能 / D.1. サポートされている機能 / CHARACTER_LENGTH関数
”021-04 コア CHARACTER_LENGTH関数 - 数える前にCHARACTER値の最後の空白を除去します”
の冒頭でも以下のような注意点が記載されています。
”character型の値は関数あるいは演算子に適用される前にtextに変換され、character値の末尾の空白が削除されることになります。”
とさらりとまとめちゃいましたが、なかなかの癖者であることがお分かりいただけたかと思います。
移行する際にこの対応が漏れてしまうと、バグに直結する部分なのでしっかりと対処したいですよね。これ。
この程度書いただけでお腹いっぱい感はありますがw、簡単な確認ログも載せておきます。
Oracle Database Oracle Databaseに慣れてると、まあ、ふむふむって結果ではあります。
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
1)
マニュアルに記載されているように、 NULL の場合は、NULLが返ります。
SCOTT@orclpdb1> set null [null]
SCOTT@orclpdb1> SELECT LENGTH(null) AS "NULL" FROM dual;
NULL
----------
[null]
2)
Oracle Database は空文字は NULL として扱われる別の癖があるため、空文字の場合は、NULL と同じ結果が返ります。
SCOTT@orclpdb1> SELECT LENGTH('') AS "Empty String" FROM dual;
Empty String
------------
[null]
3)
SCOTT@orclpdb1> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE" FROM dual;
SINGLE-BYTE SPACE
-----------------
1
4)
SCOTT@orclpdb1> SELECT LENGTH(' ') AS "MULTI-BYTE SPACE" FROM dual;
MULTI-BYTE SPACE
----------------
1
5)
SCOTT@orclpdb1> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs" FROM dual;
SINGLE-BYTE CHARs
-----------------
5
6)
SCOTT@orclpdb1> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs" FROM dual;
MULTI-BYTE CHARs
----------------
5
7)
SCOTT@orclpdb1> SELECT LENGTH('12345 ') AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;
SINGLE-BYTE CHARs + SPACEs
--------------------------
10
8)
SCOTT@orclpdb1> SELECT LENGTH('あいうえお ') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs" FROM dual;
MULTI-BYTE CHARs + MLUTI-BYTE SPACEs
------------------------------------
10
9)
SCOTT@orclpdb1> SELECT LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;
SINGLE-BYTE CHARs + SPACEs
--------------------------
10
10)
SCOTT@orclpdb1> SELECT LENGTH(CAST('12345 ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;
SINGLE-BYTE CHARs + SPACEs
--------------------------
10
11)
SCOTT@orclpdb1> SELECT LENGTH(CAST('12345' AS VARCHAR2(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;
SINGLE-BYTE CHARs + SPACEs
--------------------------
5
12)
SCOTT@orclpdb1> SELECT LENGTH(CAST('12345 ' AS VARCHAR2(10))) AS "SINGLE-BYTE CHARs + SPACEs" FROM dual;
SINGLE-BYTE CHARs + SPACEs
--------------------------
10
MySQL CHARの時の挙動に注目です。CASTしたケースの挙動はなかなかキツめな気がします。
Oracle DatabaseのLENGTH()に相当するのは、CHAR_LENGTH()ですが、空文字の扱いはOracle Databaseが特殊なので要注意なのは言うまでもありません。
+-----------+
| VERSION() |
+-----------+
| 8.0.36 |
+-----------+
1)
mysql> SELECT CHAR_LENGTH(null) AS "NULL";
+------+
| NULL |
+------+
| NULL |
+------+
2)
Oracle Databaseとは異なり。空文字は空文字としてカウントされています。こちらが標準の動き（Oracle Database側に癖があります）
mysql> SELECT CHAR_LENGTH('') AS "Empty String";
+--------------+
| Empty String |
+--------------+
| 0 |
+--------------+
3)
mysql> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
+-------------------+
| SINGLE-BYTE SPACE |
+-------------------+
| 1 |
+-------------------+
4)
mysql> SELECT CHAR_LENGTH(' ') AS "MULTI-BYTE SPACE";
+------------------+
| MULTI-BYTE SPACE |
+------------------+
| 1 |
+------------------+
5)
mysql> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
| 5 |
+-------------------+
6)
mysql> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
+------------------+
| MULTI-BYTE CHARs |
+------------------+
| 5 |
+------------------+
7)
mysql> SELECT CHAR_LENGTH('12345 ') AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
| 10 |
+----------------------------+
8)
mysql> SELECT CHAR_LENGTH('あいうえお ') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
+--------------------------------------+
| MULTI-BYTE CHARs + MLUTI-BYTE SPACEs |
+--------------------------------------+
| 10 |
+--------------------------------------+
9)
これはマニュアルに記載されている通りの結果ですね。Oracle Databaseとは異なり, CHAR(10)へキャストされた際に付加される空白は含まれていません。 なお、MySQL 8.0 リファレンスマニュアル / MySQL サーバーの管理 / MySQL Server / サーバー SQL モード / 5.1.11 サーバー SQL モード には、PAD_CHAR_TO_FULL_LENGTH の記述がありますが、最新版ではdeprecatedになっています。
mysql> SELECT CHAR_LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
+-------------------+
| SINGLE-BYTE CHARs |
+-------------------+
| 5 |
+-------------------+
9-1)
前述の特性から言うと、ちょっと怪しい挙動ですよね。なんだろこの動き。(8.0.36)
mysql> SELECT CHAR_LENGTH(CAST('12345 ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
| 10 |
+----------------------------+
9-2)
面白い挙動ですね。もう一つついでに確認しておきましょう。リテラルで指定した文字列が、CASTしたCHAR(n)のn以下の場合、CHAR(n)のnが返る訳ではなく、リテラルの文字数（後続の空白を含む）そのものが返されます。なんとなく、怪しい挙動ですね。やはり。
mysql> SELECT CHAR_LENGTH(CAST('12345 ' AS CHAR(30))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
| 10 |
+----------------------------+
9-3)
CHAR(7)よりは長い文字列を渡しているので、超過した文字は切られて 7文字となっています。これは予想通り。
mysql> SELECT CHAR_LENGTH(CAST('12345 ' AS CHAR(7))) AS "SINGLE-BYTE CHARs + SPACEs";
+----------------------------+
| SINGLE-BYTE CHARs + SPACEs |
+----------------------------+
| 7 |
+----------------------------+
MySQLのCAST()ではVARCHAR/TEXTへのキャストはできないようなので、CHAR(n)へのキャストのみ確認してみました。CHARだけ見れれば良いので十分ではありますが。CHARの時の文字列に続く空白の扱いの癖の影響なので。
PostgreSQL Oracle DatabaseのLENGTH()に相当するのは、CHAR_LENGTH()ですが、空文字の扱いはOracle Databasegが特殊なので要注意なのは言うまでもありません）
また、LENGTH()も同様に文字数を返してくるのがわかります。。。。PostgreSQLの場合、関数名も同じにできるし、NULL関連の癖に注意すれば良さそうに見えるわけですが。。。。。油断しちゃいけませんよねw
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
perftestdb=> \pset null [null]
Null表示は"[null]"です。
1)
perftestdb=> SELECT LENGTH(null) AS "NULL";
NULL
--------
[null]
2)
空文字の挙動はMySQLと同じですよね。
perftestdb=> SELECT LENGTH('') AS "Empty String";
Empty String
--------------
0
3)
perftestdb=> SELECT LENGTH(' ') AS "SINGLE-BYTE SPACE";
SINGLE-BYTE SPACE
-------------------
1
4)
perftestdb=> SELECT LENGTH(' ') AS "MULTI-BYTE SPACE";
MULTI-BYTE SPACE
------------------
1
5)
perftestdb=> SELECT LENGTH('12345') AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
6)
perftestdb=> SELECT LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
MULTI-BYTE CHARs
------------------
5
7)
perftestdb=> SELECT LENGTH('12345 ') AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
10
8)
perftestdb=> SELECT LENGTH('あいうえお ') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
MULTI-BYTE CHARs + MLUTI-BYTE SPACEs
--------------------------------------
10
9)
MySQLとPostgreSQLは同じ挙動ですね。
perftestdb=> SELECT LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
10)
空白が埋めされたわけではなく、文字列として空白を渡した場合も、トリムされて、5文字となります。（MySQLもこの動きを予想していたのになんだろあの動き）
perftestdb=> SELECT LENGTH(CAST('12345 ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
5
11)
perftestdb=> SELECT LENGTH(CAST('12345' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
12)
perftestdb=> SELECT LENGTH(CAST('12345 ' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
10
13)
perftestdb=> SELECT LENGTH(CAST('12345' AS TEXT)) AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
14)
perftestdb=> SELECT LENGTH(CAST('12345 ' AS TEXT)) AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
10
CHAR_LENGTH()でも同様に確認しておきましょう。LENGTH()でいいじゃん感じですけどもw。
perftestdb=> SELECT CHAR_LENGTH(null) AS "NULL";
NULL
--------
[null]
perftestdb=> SELECT CHAR_LENGTH('') AS "Empty String";
Empty String
--------------
0
perftestdb=> SELECT CHAR_LENGTH(' ') AS "SINGLE-BYTE SPACE";
SINGLE-BYTE SPACE
-------------------
1
perftestdb=> SELECT CHAR_LENGTH(' ') AS "MULTI-BYTE SPACE";
MULTI BYTE SPACE
------------------
1
perftestdb=> SELECT CHAR_LENGTH('12345') AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
perftestdb=> SELECT CHAR_LENGTH('あいうえお') AS "MULTI-BYTE CHARs";
MULTI-BYTE CHARs
------------------
5
perftestdb=> SELECT CHAR_LENGTH('12345 ') AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
10
perftestdb=> SELECT CHAR_LENGTH('あいうえお ') AS "MULTI-BYTE CHARs + MLUTI-BYTE SPACEs";
MULTI-BYTE CHARs + MLUTI-BYTE SPACEs
--------------------------------------
10
perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS CHAR(10))) AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
perftestdb=> SELECT CHAR_LENGTH(CAST('12345 ' AS CHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
"5
perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
perftestdb=> SELECT CHAR_LENGTH(CAST('12345 ' AS VARCHAR(10))) AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
10
perftestdb=> SELECT CHAR_LENGTH(CAST('12345' AS TEXT)) AS "SINGLE-BYTE CHARs";
SINGLE-BYTE CHARs
-------------------
5
perftestdb=> SELECT CHAR_LENGTH(CAST('12345 ' AS TEXT)) AS "SINGLE-BYTE CHARs + SPACEs";
SINGLE-BYTE CHARs + SPACEs
----------------------------
10
CHAR型の空白の扱いが癖の元なので、表の列がCHAR型の場合の動きも少し見ておきましょう。
まずは、データの準備、Oracle Database/MySQL/PostgreSQLそれぞれで、CHAR(10)の列を1列持つ表とデータを用意しました。
Oracle Database
SCOTT@orclpdb1> l
1 CREATE TABLE str
2 (
3 memo VARCHAR2(40 CHAR)
4 , c CHAR(10 CHAR)
5* )
SCOTT@orclpdb1> /
表が作成されました。
SCOTT@orclpdb1> l
1 INSERT ALL
2 INTO str(memo, c) VALUES('NULL', null)
3 INTO str(memo, c) VALUES('Empty string', '')
4 INTO str(memo, c) VALUES('SINGLE-BYTE SPACE', ' ')
5 INTO str(memo, c) VALUES('SINGLE-BYTE 2 SPACEs', ' ')
6 INTO str(memo, c) VALUES('SINGLE-BYTE CHAR and SPACE', '1 ')
7 INTO str(memo, c) VALUES('SINGLE-BYTE CHARs', '12345')
8 INTO str(memo, c) VALUES('SINGLE-BYTE CHARs', '12345 ')
9* SELECT null FROM dual
SCOTT@orclpdb1> /
7行が作成されました。
SCOTT@orclpdb1> COMMIT;
コミットが完了しました。
MySQL
mysql> CREATE TABLE str
-> (
-> memo VARCHAR(40)
-> , c CHAR(10)
-> );
Query OK, 0 rows affected (0.29 sec)
mysql> INSERT
-> INTO str(memo, c)
-> VALUES('NULL', null)
-> ,('Empty string', '')
-> ,('SINGLE-BYTE SPACE', ' ')
-> ,('SINGLE-BYTE 2 SPACEs', ' ')
-> ,('SINGLE-BYTE CHAR and SPACE', '1 ')
-> ,('SINGLE-BYTE CHARs', '12345')
-> ,('SINGLE-BYTE CHARs', '12345 ')
-> ;
Query OK, 7 rows affected (0.03 sec)
Records: 7 Duplicates: 0 Warnings: 0
mysql>
PostgreSQL
perftestdb=> CREATE TABLE str
perftestdb-> (
perftestdb(> memo VARCHAR(40)
perftestdb(> , c CHAR(10)
perftestdb(> );
CREATE TABLE
perftestdb-> INTO str(memo, c)
perftestdb-> VALUES('NULL', null)
perftestdb-> ,('Empty string', '')
perftestdb-> ,('SINGLE-BYTE SPACE', ' ')
perftestdb-> ,('SINGLE-BYTE 2 SPACEs', ' ')
perftestdb-> ,('SINGLE-BYTE CHAR and SPACE', '1 ')
perftestdb-> ,('SINGLE-BYTE CHARs', '12345')
perftestdb-> ,('SINGLE-BYTE CHARs', '12345 ')
perftestdb-> ;
INSERT 0 7
perftestdb=>
リテラル値をキャストした場合とは少々異なる結果になりました。
MySQLとPostgreSQLは同一の挙動を示します。MySQLの場合、'12345 'をCHAR(10)へCASTした時の挙動の違い、やはり気になりますね。
Oracle Database
SCOTT@orclpdb1> SELECT memo, CASE WHEN c IS NULL THEN c ELSE '"'||c||'"' END AS "CHAR(10)", LENGTH(c) FROM str;
MEMO CHAR(10) LENGTH(C)
---------------------------------------- ------------------------------------ ----------
NULL [null] [null]
Empty string [null] [null]
SINGLE-BYTE SPACE " " 10
SINGLE-BYTE 2 SPACEs " " 10
SINGLE-BYTE CHAR and SPACE "1 " 10
SINGLE-BYTE CHARs "12345 " 10
SINGLE-BYTE CHARs "12345 " 10
MySQL
mysql> SELECT memo, CASE WHEN c IS NULL THEN c ELSE CONCAT('"', c, '"') END AS "CHAR(10)", CHAR_LENGTH(c) FROM str;
+----------------------------+----------+----------------+
| memo | CHAR(10) | CHAR_LENGTH(c) |
+----------------------------+----------+----------------+
| NULL | NULL | NULL |
| Empty string | "" | 0 |
| SINGLE-BYTE SPACE | "" | 0 |
| SINGLE-BYTE 2 SPACEs | "" | 0 |
| SINGLE-BYTE CHAR and SPACE | "1" | 1 |
| SINGLE-BYTE CHARs | "12345" | 5 |
| SINGLE-BYTE CHARs | "12345" | 5 |
+----------------------------+----------+----------------+
PostgreSQL
perftestdb=> SELECT memo, CASE WHEN c IS NULL THEN c ELSE '"'||c||'"' END AS "CHAR(10)", LENGTH(c) FROM str;
memo | CHAR(10) | length
----------------------------+----------+--------
NULL | [null] | [null]
Empty string | "" | 0
SINGLE-BYTE SPACE | "" | 0
SINGLE-BYTE 2 SPACEs | "" | 0
SINGLE-BYTE CHAR and SPACE | "1" | 1
SINGLE-BYTE CHARs | "12345" | 5
SINGLE-BYTE CHARs | "12345" | 5
明日の、JPOUG Advent Calendar 2024は、rkondoさん、MySQL Advent Calendar 2024は、今の所空いていますが誰かが書くはずw、そして、PostgreSQL Advent Calendar 2024は、kingtomo1122さん(シリーズ1)、yamatattsuさん(シリーズ2)です。
メーリークリスマスには少し早いですが、メリークリスマス！
良いお年をお迎えください。
では、また来年！（DTMのポストはまだする予定、DTMの全部俺アドベントカレンダーやってますのでw ）
Enjoy! SQL!
関連エントリー
・標準はあるにはあるが癖の多いSQL 全部俺 #1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺 #2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺 #3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺 #4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺 #5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺 #6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺 #7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺 #8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺 #9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺 #10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺 #11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺 #12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺 #14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺 #16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺 #17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺 #18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺 #19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺 #20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺 #25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺 おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #8 - Hash Joinさせるにも癖が出る
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #9、BOOLEAN型にも癖が出る
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #10、BOOLEAN型にも癖が出る（後編）
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #10、BOOLEAN型にも癖が出る（後編）の おまけ - SQL*PlusのautotraceでSQL Analysis Reportが出力される！ (23ai〜)
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #11 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（前編）
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #12 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（後編）ー 列エイリアスの扱いにも癖がある！
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #13 - コメント書くにも癖がある
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #14 - コメントを書く位置にも癖がでる (SQL Clientにも癖がある)
・帰ってきた！ 標準はあるにはあるが癖の多いSQL #15 - 実行計画でスカラー副問合せの見せ方にも癖がでる
最近のコメント