考えられる理由は2つありますが、その理由は...
これらの昇給はどちらもメッセージログに表示されません
ログに記録されていません
まず、NOTICE 通常、デフォルト設定ではデータベースログに書き込まれません。ここでマニュアルを引用します：
log_min_messages（enum）サーバーログに書き込むメッセージレベルを制御します。有効な値は
DEBUG5です。 、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、ERROR、LOG、FATAL、およびPANIC。 （...）
デフォルトは警告です 。LOGに注意してください ここでは、client_min_messagesとはランクが異なります。 。
大胆な強調鉱山。別のデフォルトにも注意してください（NOTICE ）client_min_messagesの場合 （マニュアルの前の項目）。
無効なテスト
次に、行式がどのように評価されるかを検討します。テストrow_variable IS NULL TRUEを返します if（そしてその場合のみ）すべての単一要素 NULLです 。次の例を考えます：
SELECT (1, NULL) IS NULL AS a -- FALSE
,(1, NULL) IS NOT NULL AS b -- also FALSE
両方 式はFALSEを返します 。つまり、行（またはレコード）変数(1, NULL) NULLでもありません 、NOT NULLでもありません 。したがって、両方のテストが失敗します。
-> SQLfiddle 詳細をお知らせします。
CHECKでのこの動作の詳細、説明、リンク、および可能なアプリケーション この関連する回答の制約：
一連の列に対するNOTNULL制約
NULLを使用してレコード変数を割り当てることもできます（rec := NULL ）、これにより、すべての要素がNULLになります-タイプが既知の行タイプの場合。それ以外の場合は、匿名レコードを処理しており、構造が定義されておらず、最初から要素にアクセスできません。ただし、rowtypeの場合はそうではありません。 あなたの例のように（これは常によく知られています）。
解決策：FOUND
SELECT * INTOから行を受け取ったかどうかをテストする正しい方法は何ですか ？
行が割り当てられている場合でも、行がNULLになる可能性があることを考慮する必要があります。クエリは、NULL値の束を返す可能性があります（クエリのテーブル定義でNULL値が許可されている場合）。このようなテストは、設計上信頼できません。
シンプルで安全なアプローチがあります。 GET DIAGNOSTICS ...を使用します または（該当する場合）特別な変数FOUND ：
SELECT * FROM my_table WHERE owner_id = 6 INTO my_var;
IF NOT FOUND THEN
RAISE NOTICE 'Query did not return a row!';
END IF;
マニュアルの詳細。