web-dev-qa-db-ja.com

セッション内の将来のすべてのテーブル作成ステートメントのデフォルト所有者を設定する方法はPostgreSQLにありますか

Cobolデータ（インデックスファイル）をデータベースに転送するプログラムがあります。

これまでは、データをOracleデータベースに転送していました。

プログラムの最初に、ユーザーsysでログインし、現在のスキーマをinkに変更しました。 inkにはテーブルを作成する権限がないため、この方法でこれを行いました。

次に、テーブルを作成し、テーブルの所有者は自動的にinkではなくsysになりました。

最近、データベースをOracleからPostgresに切り替えました。

ここでは「postgres」としてログインし、次のコマンドで「ink」スキーマに切り替えます。

set search_path to 'ink';

次に、テーブルを作成します。テーブルの所有者は、postgresではなくinkになります。したがって、この動作は逆になります。

Oracleデータベースと同じ動作をするために何をしなければなりませんか：

私のシナリオでは、テーブルの所有者は自動的にinkではなくpostgresになるはずです。

書く必要がないといいですね

ALTER TABLE ... OWNER TO ink;

各create tableコマンドの後。

postgresqloracleddl
4
Wolfgang Adamec

Oracleでは、スキーマとユーザーは同じものです。 Postgresではそうではありません。

したがって、「Postgresランド」でOracleで行った操作を直接「マッピング」することはできません。テーブルはalwaysであり、最初にそれを作成したユーザーが所有しています。これを変更する方法はありません。

ユーザーにinkにテーブルを作成する権限を与えたくない場合、「Postgres」の方法は、そのユーザーにテーブルに対するすべての権限を与えることです。 Oracleとは異なり、スキーマで作成されたオブジェクトに対してdefault特権を確立できます。各テーブルを作成した後で、それらを付与することを覚えておく必要はありません。

create schema ink;
grant usage on schema ink to ink;
alter default privileges 
   in schema ink
   grant all privileges on tables to ink;

その後に作成されたすべてのテーブルには、定義された権限が自動的に付与されます。つまり、inkは、そのユーザーが所有者ではないため、ドロップ以外のすべての操作を実行できます。これはOracleソリューションとは異なります。

3
a_horse_with_no_name

警告される：私はPostgreSQLに比較的慣れていないので、これが良い習慣であるかどうかはわかりませんが...

これに対処できると私が考える1つの方法は、次のように、データベース内のすべてのオブジェクトを作成したプロセスの最後にREASSIGN OWNEDステートメントを実行することです。

REASSIGN OWNED BY CURRENT_USER TO ink;

このようにすると、テーブルがpostgresユーザーによって一時的に所有されている場合でも、作成プロセスが終了すると、それらはinkによって所有されていることがわかります。

2
Paulo

inkにデータベース内にテーブルを作成する権限を与え、inkとしてデータベースに接続します。次に、そこに作成するすべてのテーブルはinkが所有します。

PostgreSQLはこれに対してOracleとは異なるアプローチをとっています。スキーマと所有者は2つの異なる「もの」です。

0
Marco