A normal relationship between separately-created objects. The dependent object can be dropped without affecting the referenced object. The referenced object can only be dropped by specifying <literal>CASCADE</literal>, in which case the dependent object is dropped, too. Example: a table column has a normal dependency on its data type. 個別に作成されたオブジェクト間の通常の関係です。 依存するオブジェクトは参照されるオブジェクトに影響を与えずに削除できます。 参照されるオブジェクトはCASCADEを指定することによってのみ削除できます。 この場合は依存するオブジェクトも削除されます。 例：テーブルの列はそのデータ型に対して通常の依存関係を持ちます。

The dependent object can be dropped separately from the referenced object, and should be automatically dropped (regardless of <literal>RESTRICT</literal> or <literal>CASCADE</literal> mode) if the referenced object is dropped. Example: a named constraint on a table is made auto-dependent on the table, so that it will go away if the table is dropped. 依存するオブジェクトは参照されるオブジェクトから独立して削除できます。 そして、参照されるオブジェクトが削除される時は（RESTRICTもしくはCASCADEモードに関わりなく）依存するオブジェクトも自動的に削除されなければなりません。 例：テーブル上の名前付き制約はテーブル上に自動設定されているため、テーブルが削除されるとなくなります。

The dependent object was created as part of creation of the referenced object, and is really just a part of its internal implementation. A direct <command>DROP</command> of the dependent object will be disallowed outright (we'll tell the user to issue a <command>DROP</command> against the referenced object, instead). A <command>DROP</command> of the referenced object will result in automatically dropping the dependent object whether <literal>CASCADE</literal> is specified or not. If the dependent object has to be dropped due to a dependency on some other object being removed, its drop is converted to a drop of the referenced object, so that <literal>NORMAL</literal> and <literal>AUTO</literal> dependencies of the dependent object behave much like they were dependencies of the referenced object. Example: a view's <literal>ON SELECT</literal> rule is made internally dependent on the view, preventing it from being dropped while the view remains. Dependencies of the rule (such as tables it refers to) act as if they were dependencies of the view. 依存するオブジェクトは参照されるオブジェクトの作成時に作成されたもので、実際には内部実装の一部に過ぎません。 依存するオブジェクトに対してDROPコマンドを直接的に実行できません （その代わりに、参照されるオブジェクトに対してDROPを実行するように指示されます）。 参照されるオブジェクトにDROPを実行すると、CASCADEが指定されているかどうかに関わらず、依存するオブジェクトも削除されます。 削除されるオブジェクトへの依存関係で依存しているオブジェクトを削除しなければらない場合、その削除は参照されるオブジェクトの削除に変換されます。 ですから依存しているオブジェクトのNORMALとAUTO依存関係は、参照されるオブジェクトの依存関係に非常に似通った振る舞いをします。 例：ビューのON SELECTルールがビューに依存して内部的に作られ、ビューが存在する限り削除されることを防ぎます。 ルールの依存関係（たとえばそれが参照するテーブル）はビューの依存関係であるかのように振る舞います。

The dependent object was created as part of creation of the referenced object, and is really just a part of its internal implementation; however, unlike <literal>INTERNAL</literal>, there is more than one such referenced object. The dependent object must not be dropped unless at least one of these referenced objects is dropped; if any one is, the dependent object should be dropped whether or not <literal>CASCADE</literal> is specified. Also unlike <literal>INTERNAL</literal>, a drop of some other object that the dependent object depends on does not result in automatic deletion of any partition-referenced object. Hence, if the drop does not cascade to at least one of these objects via some other path, it will be refused. (In most cases, the dependent object shares all its non-partition dependencies with at least one partition-referenced object, so that this restriction does not result in blocking any cascaded delete.) Primary and secondary partition dependencies behave identically except that the primary dependency is preferred for use in error messages; hence, a partition-dependent object should have one primary partition dependency and one or more secondary partition dependencies. Note that partition dependencies are made in addition to, not instead of, any dependencies the object would normally have. This simplifies <command>ATTACH/DETACH PARTITION</command> operations: the partition dependencies need only be added or removed. Example: a child partitioned index is made partition-dependent on both the partition table it is on and the parent partitioned index, so that it goes away if either of those is dropped, but not otherwise. The dependency on the parent index is primary, so that if the user tries to drop the child partitioned index, the error message will suggest dropping the parent index instead (not the table). 依存するオブジェクトは参照されるオブジェクトの生成の一環で作成され、実際にはこれは内部的な実装の一部に過ぎません。 しかし、INTERNALとは違って複数の参照されるオブジェクトが存在します。 参照されているオブジェクトの少なくとも１つが削除されない限り、依存するオブジェクトは削除されてはいけません。 もし参照されているオブジェクトの一つが削除されたら、CASCADEが指定されているかどうかに関わらず、依存しているオブジェクトは削除されるべきです。 また、INTERNALとは違って、依存オブジェクトが依存しているオブジェクトを削除してもパーティション参照オブジェクトを自動的に削除することにはなりません。 ですからその削除処理によって他の経路でこれらのオブジェクトの少なくとも１つに連鎖波及しない限り、削除は拒否されます。 （たいていの場合、依存するオブジェクトはすべての非パーティション依存関係を、少なくとも１つのパーティション参照オブジェクトと共有するので、この制限によって連鎖削除をブロックすることにはなりません。） エラーメッセージで優先的に主パーティションが使われることを除くと、主および二次パーティション依存関係は同じように振る舞います。 よって、パーティション依存オブジェクトは一つの主パーティション依存関係と1つ以上の二次パーティション依存関係を持つはずです。 パーティション依存関係は、オブジェクトが通常持っている依存関係に加えて作成されるのであり、それを置き換えるものではないことに注意してください。 これによってATTACH/DETACH PARTITION操作が簡単になります。 パーティション依存関係は追加されるか削除されるかのどちらかになります。 例：子パーティションインデックスは、それが作成されているパーティションテーブルと親パーティションインデックスの両方にパーティション依存します。 ですから、このどちらかが削除されると削除されますが、それ以外の場合には削除されません。 親インデックスへの依存関係は主なので、ユーザが子パーティションインデックスを削除しようとすると、エラーメッセージは（テーブルではなく）親インデックスを削除するように示唆します。

The dependent object is a member of the <firstterm>extension</firstterm> that is the referenced object (see <link linkend="catalog-pg-extension"><structname>pg_extension</structname></link>). The dependent object can be dropped only via <link linkend="sql-dropextension"><command>DROP EXTENSION</command></link> on the referenced object. Functionally this dependency type acts the same as an <literal>INTERNAL</literal> dependency, but it's kept separate for clarity and to simplify <application>pg_dump</application>. 依存するオブジェクトは参照されるオブジェクトの拡張のメンバです（pg_extension参照）。 依存するオブジェクトは参照されるオブジェクトに対するDROP EXTENSION経由でのみ削除できます。 機能的にはこの種類の依存関係はINTERNAL依存関係と同様に動作しますが、明確さとpg_dumpを単純化するために別々に保持されます。

The dependent object is not a member of the extension that is the referenced object (and so it should not be ignored by <application>pg_dump</application>), but it cannot function without the extension and should be auto-dropped if the extension is. The dependent object may be dropped on its own as well. Functionally this dependency type acts the same as an <literal>AUTO</literal> dependency, but it's kept separate for clarity and to simplify <application>pg_dump</application>. 依存するオブジェクトは参照されるオブジェクトの拡張のメンバではありません（そしてそれゆえpg_dumpによって無視されません）が、拡張なしに機能することが出来ず、拡張自体が削除される時に自動的に削除されるでしょう。 依存するオブジェクトは、同様にそれ自身で削除されるかもしれません。 機能的にはこの種類の依存関係はAUTO依存関係と同様に動作しますが、明確さとpg_dumpを単純化するために別々に保持されます。