MySQL 8.0.19 のリリースノート にこんなのがあって、

MySQL now supports datetime literals with time zone offsets, such as '2019-12-11 10:40:30-05:00', '2003-04-14 03:30:00+10:00', and '2020-01-01 15:35:45+05:30'; these offsets are respected but not stored when inserting such values into TIMESTAMP and DATETIME columns; that is, offsets are not displayed when retrieving the values.

一瞬 DATETIME 型にタイムゾーンが来たか！ と喜んだんだけど、よく読んだら違った。

日時リテラルにオフセットを指定できるようになっただけだった。

日本時間のサーバーで +09:00 を指定しても時刻はそのまま。当たり前。

mysql> SELECT CONVERT('2020-01-28 00:00:00+09:00', DATETIME);
+------------------------------------------------+
| …

1/13 に MySQL 8.0.19 がリリースされたんで、リリースノート を眺めてると気になるのがいくつか。

Important Change: MySQL now supports explicit table clauses and table value constructors according to the SQL standard. These have now been implemented, respectively, as the TABLE statement and the VALUES statement

TABLE と VALUES ステートメントが追加されたみたい。 さすがMySQL! パッチリリースで新しい構文を突っ込んでくるッ! そこにシビれる!あこがれるゥ!

TABLE

TABLE は、テーブルの中身全部を取り出す SELECT のようなものらしい。

TABLE t で SELECT * FROM t と同じ意味らしい。WHERE や JOIN …

MySQL 8.0.19。MySQL 8.0 の「メンテナンスリリース」です。
8.0.19より前のMySQLには、「標準SQLのひとつであるVALUES文が実装されていない」という重大な不具合が含まれていたため、バグ修正として本リリースに含まれたようです（真に受ける人がいると困るので、無粋ながら説明しておくと、これ、思いっきり「新機能」ですからね！ ）

…

今週頭(2020-01-13)にMySQL 8.0.xのメンテナンスリリースである8.0.19が出ました。

多くの機能が追加されましたが、本ブログではあまり他の人が取り上げなさそうなものをご紹介します。
そのうちの一つ明示表(Explicit Table)について。

リリースノートには以下の記述があります。

Important Change: MySQL now supports explicit table clauses and table value constructors according to the SQL standard.

VALUESについては以前以下の発表の中で触れました。Db2とPostgreSQLがサポートしている形式までいっきょにMySQL …

TL;DR

• MySQL 8.0 で LOAD DATA INFILE LOCAL を利用するには、
• サーバとクライアント両方で local-infile パラメータを ON にする必要がある
• セキュリティ強化のため、8.0から LOAD DATA INFILE LOCAL はデフォルトで無効にされた

MySQL 8.0 で LOAD DATA INFILE LOCAL が通らない

Loading local data is disabled; this must be enabled on both the client and server sides エラー*1で LOAD DATA INFILE LOCAL が通らなくなっていた 。

mysql> LOAD DATA LOCAL INFILE 'file.csv' INTO TABLE tbl SET name=@1, created_at=@2;
ERROR 3948 (42000): …

TL;DR

explicit_defaults_for_timestamp …

訳あって、MySQLで「GEOMETRY型のカラムに、いったん SRID=0で登録したあと、一気に正しいSRIDに変換する」ということをやろうとしたところ、思惑通りにいかず随分悩んだので、整理しておきます。

やろうとしたこととエラー発生

　ここではシンプルな例に置き換えた再現実験で紹介します。

　まず、GEOMETRY型を入れられるテーブルを作りデータを1件登録します。

CREATE TABLE g1 (g GEOMETRY);
INSERT INTO  g1 VALUES (ST_GeomFromText("POINT(35 135)"));

　SRIDを指定していないので、SRID=0で登録されています。axis-orderは lat-long です（というか、そうなっていることを期待して登録しました）。登録された内容を確認してみます。

mysql> SELECT …

TL;DR

• 過去のツイート履歴がCSVからJSに変わったっぽい
• でも大丈夫、俺達には JSON_TABLE関数 があるから

かつてはCSVだったツイート履歴、最近ダウンロードしてみたらJSファイルになっていた。しかもでかい。

$ mkdir work
$ cd work
$ unzip ../twitter-2019-12-20-ce0bbf92f327035a47c135f037e0568f6166df65f5f1011bc9d0bc2b6b9b6c3f.zip
..

$ du -sh .
239M    .

$ ll -h tweet.js
-rwxrwxrwx 1 yoku0825 yoku0825 47M Dec 20 09:00 tweet.js

しかもこのJS、よしなにpretty printされていてグレッパビリティが悪い。

$ head tweet.js
window.YTD.tweet.part0 = [ {
  "retweeted" : false,
  "source" : "<a href=\"https://mobile.twitter.com\" …

　DROP DATABASE IF EXISTS ... で存在しないデータベースをドロップしようとしたときに、WARNING が表示されない事象があったので紹介します。

IF EXISTS (テーブルの場合)

　MySQL のDROP文には "IF EXISTS" というオプションがあり、たとえばテーブルの場合は、以下のように使います。

mysql> use test
mysql> DROP TABLE IF EXISTS mytable999;                                                                                             
Query OK, 0 rows affected, 1 warning (0.02 sec)

　mytable999 というテーブルは存在しませんが、IF EXISTS 句のおかげでエラーにはならず正常終了しています。
…

TL;DR

• オンライン変更は SYSTEM_VARIABLES_ADMIN 権限。 SUPER は非推奨。
• SET PERSIST_ONLY は SYSTEM_VARIABLES_ADMIN 権限 && PERSIST_RO_VARIABLES_ADMIN 権限

ふとコードを読んでいる時に SET PERSIST_ONLY には SUPER 権限は絡んでなさそうなことに気が付いたので試してみる。

  /* for dynamic variables user needs SUPER_ACL or SYSTEM_VARIABLES_ADMIN */
  if (!static_variable) {
    if (!sctx->check_access(SUPER_ACL) &&
        !(sctx->has_global_grant(STRING_WITH_LEN("SYSTEM_VARIABLES_ADMIN"))
              .first)) {
      my_error(ER_SPECIFIC_ACCESS_DENIED_ERROR, MYF(0),
               "SUPER or SYSTEM_VARIABLES_ADMIN");
      return 1;
    }
  } else {
    /*
 …