[pgsql-jp: 25651] Re: 外部キーのリファレンス先のテーブル所有者

[Jun Kitamura]

北村＠zoozee です。

> 和田＠横から失礼します。

とんでもないです。ありがとうございます。

> Tatsuo Ishii wrote:
> 
> > > 7.0.3 でも、7.1.3 でも同じ動作です。
> > >
> > > ムリなのはしょうがないのですが、この仕様、皆さんは納得できますか？
> > 
> > 7.2のGRANT REFERENCESで解決できない問題なのですか?
>
> 私もそう思ったのですが、なんだかちょっとおかしいので。
> （cygwinの7.2.1-1で試しました）
> まず参照されるtableを作り、
(snip)
> となって自分がownerなtableを削除できません。実際にはtest1のtriggerの
> 方が削除できないようなので、
(snip)
> 念のため GRANT ALL もやってみましたが変化ありません。
> INSERTとDELETEが別なのでINSERT権限だけでは自分で追加した
> レコードを削除できないのと似たようではありますが。。。

私も(重い腰を上げて(汗)) 7.2.1 をインストールして、実験してみました。
結果は和田さんのものと同じでした。
たしかに、自分の所有するテーブル(test2)が削除できませんでした。

> そもそも別々にGRANTできるのに、GRANT TRIGGER してない状態で
>  ON DELETE な REFERENCE を作れたのがおかしいような気がします。

TRIGGER と、implicit TRIGGER は別扱いだったような。
なので、REFERENCE と TRIGGER を別物として扱うのは、納得できます。
test2 テーブルが削除できないのも、test1 に対する TRIGGER 権限よりも
ALTER TABLE .. DROP CONSTRAINT の実行権限(=テーブルオーナーか否か)になっ
てしまうのでは無いでしょうか。(だとすればなんとなく納得です(test2 テーブ
ルが削除できない状況に満足しているわけじゃないです))。

とりあえず、解決の糸口は見えたので「保留」です(汗)。

余談なんですが、REFERENCE 権限さえあれば、SELECT 権限が無くても良いので、
総当りすれば test2 を使って test1 のキー値に何があるか調べることができま
すね (test1 がキー値を隠す意味(というか、そういうシチュエーション)が無い
ですが)。

一応サマリ
-------ここから
・外部キーのリファレンス先のテーブル所有者が違う場合
　→リファレンス先テーブルで GRANT REFERENCE。
　　(SELECT 権限が無くても、REFERENCE さえあれば可能)
　　→(問題点)自テーブルが削除できなくなる。

 ユーザA
  CREATE TABLE t1(
   a int4,
    PRIMARY KEY(a),
   b int4
  );
  GRANT REFERENCES ON t1 TO ユーザB

 ユーザB
  CREATE TABLE t2 (
   a int4,
    CONSTRAINT t2_a
     FOREIGN KEY(a)
     REFERENCES t1(a)
     ON UPDATE CASCADE
     ON DELETE CASCADE,
   c int4
  );
  DROP TABLE t2; -- これが実行できない
  ERROR:  t1: Must be table owner.
------ここまで

# 7.2 のすごさと便利さで色々遊んでしまったので時間が・・・・。