rink_rewさんの投稿一覧

ちょうど類似の投稿があったので私も調べて見たのですが、本問題でも説明されているように、COALESCE関数ではすべての引数は同じデータ型でなければならず、実行例のとおりエラーになります。
https://mondai.ping-t.com/g/posts/2173

ちなみに黒本（オラクルマスター教科書）などの記載も同様で「引数は同じデータ型である必要がある」という記載になってますね。

Oracleデータベースとしては様々な場面で暗黙的なデータ型変換をしてくれますが、本問題の「参考」に示されているように、COALESCE関数では、すべての引数は同じデータ型でなければならないため、異なるデータ型の値を指定すると基本的にエラーとなります。

SQL> desc test_coalesce01 
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COL1						    NUMBER
 COL2						    VARCHAR2(20)

SQL> SELECT * FROM test_coalesce01;

      COL1 COL2
---------- --------------------
	10 100

SQL> SELECT COALESCE(col1, col2) FROM test_coalesce01;
SELECT COALESCE(col1, col2) FROM test_coalesce01
                      *
行1でエラーが発生しました。:
ORA-00932: データ型が一致しません: NUMBERが予想されましたがCHARです。

もちろん、明示的に変換すればエラーにはなりません。

SQL> SELECT COALESCE(to_char(col1), col2) FROM test_coalesce01;

COALESCE(TO_CHAR(COL1),COL2)
----------------------------------------
10

SQL> SELECT COALESCE(col1, to_number(col2)) FROM test_coalesce01;

COALESCE(COL1,TO_NUMBER(COL2))
------------------------------
			    10

SQL> 

公式マニュアルに記載の文章については、文字->数値や日付->文字のような、よく言う暗黙的データ変換ではなく、同じ数値<->数値や日付<->日付での処理を指しているようです。

DATE型とTIMESTAMP型で試して見たら、型は異なりますがエラーにならずに結果が返されました。

SQL> desc test_coalesce_conv01
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 COL1						    TIMESTAMP(6)
 COL2						    DATE

SQL> SELECT * FROM test_coalesce_conv01;

COL1
---------------------------------------------------------------------------
COL2
--------
25-12-08 05:59:08.325928
25-01-01


SQL> SELECT COALESCE(col1, col2) FROM test_coalesce_conv01;

COALESCE(COL1,COL2)
---------------------------------------------------------------------------
25-12-08 05:59:08.325928

SQL> 

「LED」は、辞書で引こうとすると
「LE」よりは後ろになる。
※広辞苑でいえば、「愛(あい)」よりも「間(あいだ)」の方が後ろになるイメージ。

同じ理論で「LAN」は「LE」よりは前になる。
※広辞苑でいうところの、「間(あいだ)」が「赤(あか)」より前になるイメージ。

「HI～」については、「LE」よりも前。
※そもそも頭文字が「L」より前な「H」なので、
辞書で引いたら圧倒的に早く出てくるといった具合。

そうですね。その理解で良いと思います。

この問題自体は運営さんが既に修正してくれたみたいですが、PostgreSQLの公式マニュアルでも「SELECT FOR UPDATE が〜〜」や「SELECT FOR SHARE を〜〜」といった表現がバンバン使われてはいるので、実際の試験では迷わない設問が出ることを祈りたいですね。

https://www.postgresql.jp/document/14/html/explicit-locking.html#LOCKING-ROWS

その選択肢で言いたい話は、こういうことですよね？
列定義のサイズ（長さ）を指しているので、「列のサイズ」のほうがしっくりくるかなと思いました。
逆に「データのサイズ」だと、実際に格納されているデータのサイズを指しているように感じられました。

SQL> desc tbl_a
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID						    NUMBER
 NAME						    VARCHAR2(10)

SQL> desc tbl_b
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ID						    NUMBER
 NAME						    VARCHAR2(20)   <--- サイズが異なる

SQL> select * from tbl_a; 

	ID NAME
---------- ----------
	 1 AAA
	 2 BBB

SQL> select * from tbl_b;

	ID NAME
---------- --------------------
	 1 AAA
	 3 CCC

SQL> select id, name from tbl_a
  2  union
  3  select id, name from tbl_b;

	ID NAME
---------- --------------------
	 1 AAA
	 2 BBB
	 3 CCC　　　　　　　　　　　　<--- 正常に実行できる

SQL>