« 標準はあるにはあるが癖の多いSQL 全部俺 #4 リテラル値での除算の内部精度も違うのよ! | トップページ | 標準はあるにはあるが癖の多いSQL 全部俺 #6 時間厳守! »

2020年12月 5日 (土)

標準はあるにはあるが癖の多いSQL 全部俺 #5 和暦変換機能ある方が少数派

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の5日目です。

これもあるのが当たり前だよねーと思っていると、ないの!! と言うありがちなネタで、日付の和暦変換など、

Oracleだとグローバリゼーション対応で組み込まれてます。昨年令和に切り替わったばかりなので、Oracleが中心の方々は、MySQLやPostgreSQL界隈は大丈夫なの?間に合うの?なんて話題も多かったことだろうと思います。
私もそうでした。でも心配する必要のあるのはOracleだけだったw と言う取り越し苦労でした。はい。

まず、Oracle

SCOTT@orcl> r
1 SELECT
2 TO_CHAR(
3 SYSDATE
4 , 'EEYY/MM/DD'
5 , 'NLS_CALENDAR = ''JAPANESE IMPERIAL'''
6 )
7 FROM
8* DUAL

TO_CHAR(SYSDATE,'EEYY/MM/DD','NLS_CALE
--------------------------------------
令和02/12/05

経過: 00:00:00.01
SCOTT@orcl>


Oracle 19c - Databaseグローバリゼーション・サポート・ガイド 3.7.1.4 紀元の年
https://docs.oracle.com/cd/F19136_01/nlspg/setting-up-globalization-support-environment.html#GUID-9674F2F3-D3A2-436A-83D1-7A8AC0D2B1ED


実は、年号が平成から令和切り替わると言う時になって始めて知ったのですが、みんな対応しているわけではないのですね。。和暦。
そう言う意味では、顧客要求をしっかり拾っていたと言うことなのでしょうね。

まだまだ、知らないことが多いSQLな世界w 


PostgreSQL

ないのでUDF等で対応ですよね

PostgreSQLの新元号への対応について
https://www.ashisuto.co.jp/support/gengo/product/postgresql.html

MySQL

ないのでUDF等で対応ですよね

と言うことで、RDS/Auroraにつても同様 この記事、現在は Snowflake - Principal Cloud Support Engineer の松崎さんの記事ですね!
https://aws.amazon.com/jp/blogs/news/how-to-determine-whether-kaigen-japan-era-name-transition-affects-your-mysql-compatible-engines-running-on-rds/"

Redshift
ないので、必要ならUDF等で対応ですよね




実行計画は、SQL文のレントゲン写真だ! Oracle Database編 (全部俺) Advent Calendar 2019

標準はあるにはあるが癖の多いSQL 全部俺 #1 Pagination
標準はあるにはあるが癖の多いSQL 全部俺 #2 関数名は同じでも引数が逆の罠!
標準はあるにはあるが癖の多いSQL 全部俺 #3 データ型確認したい時あるんです
標準はあるにはあるが癖の多いSQL 全部俺 #4 リテラル値での除算の内部精度も違うのよ!/a>

Oracle, SQL, MySQL, PostgreSQL, AWS |

コメント

コメントを書く