serial 実際のデータ型ではありません。マニュアルには次のように記載されています：
データ型
smallserial、serialおよびbigserial真の型ではありませんが、一意の識別子列を作成するための表記上の便宜にすぎません
疑似データ型は、次のすべてを実行して解決されます：
-
tablename_colname_seqという名前のシーケンスを作成します -
タイプが
integerの列を作成します （またはint2/int8それぞれsmallserial/bigserial） -
列を
NOT NULL DEFAULT nextval('tablename_colname_seq')にします -
列にシーケンスを所有させて、自動的に削除されるようにします
システムはしません これらすべてを手動で行ったか、疑似データ型serialを使用して行ったかを確認してください 。 pgAdminはリストされた機能をチェックし、すべてが満たされている場合、リバースエンジニアリングされたDDLスクリプトは、一致するserialで簡略化されます。 タイプ。機能の1つが満たされない場合、この単純化は行われません。それはpgAdminが行うことです。基礎となるカタログテーブルについては、すべて同じです。 serialはありません そのように入力します。
所有するシーケンスの名前を自動的に変更する方法はありません。実行できます：
ALTER SEQUENCE ... RENAME TO ...
あなたがしたように。システム自体は名前を気にしません 。列DEFAULT OIDを格納します （'foo_pkey_seq'::regclass ）、それを壊すことなくシーケンスの名前を変更できます-OIDは同じままです。データベース内の外部キーや同様の参照についても同じことが言えます。
主キーの暗黙的なインデックスは、PK制約の名前にバインドされますが、はバインドされません。 テーブルの名前を変更する場合は変更します。 Postgres 9.2以降では、
を使用できます。ALTER TABLE ... RENAME CONSTRAINT ..
それも修正します。
テーブル名を参照して名前が付けられたインデックスもあります。同様の手順：
ALTER INDEX .. RENAME TO ..
テーブル名へのあらゆる種類の非公式な参照を持つことができます。システムは、任意の名前を付けることができるオブジェクトの名前を強制的に変更することはできません。そしてそれは気にしません。
もちろん、これらの名前を参照するSQLコードを無効にする必要はありません。明らかに、アプリケーションロジックが名前を参照しているときに名前を変更する必要はありません。通常、これはインデックス、シーケンス、または制約の名前では問題になりません。これらは通常、名前で参照されないためです。
Postgresは、オブジェクトの名前を変更する前に、オブジェクトのロックも取得します。したがって、同時トランザクションがある場合 問題のオブジェクト、つまりRENAMEに何らかのロックがかかっているオープン これらのトランザクションがコミットまたはロールバックされるまで、操作は停止します。
システムカタログとOID
データベーススキーマは、システムスキーマpg_catalogのシステムカタログのテーブルに保存されます。 。マニュアルのすべての詳細はこちら。自分が何をしているのか正確にわからない場合は、これらのテーブルをいじってはいけません。 。 1つの誤った動きで、データベースを壊す可能性があります。 Postgresが提供するDDLコマンドを使用します。
最も重要なテーブルのいくつかについて、Postgresはオブジェクト識別子の型と型キャストを提供してOIDの名前を取得し、その逆も同様です。いいね：
SELECT 'foo_pkey_seq'::regclass
スキーマ名がsearch_pathにある場合 テーブル名は一意であり、次と同じになります。
SELECT oid FROM pg_class WHERE relname = 'foo_pkey_seq';
ほとんどのカタログテーブルの主キーはoidです。 内部的には、ほとんどの参照はOIDを使用します。