С каким Постгресом Вы работаете?

Я работаю в Постгресе, естественно, нельзя объять необъятное.
Решение Ваших проблем, или части, находится в системных таблицах.

Основа pg_class; там есть relname, relkind = имя таблицы, relkind=’r’ – таблица БД, то , с переводом на русский у меня трудно.
http://www.postgresql.org/docs/7.4/static/catalog-pg-class.html

Если в Вашей базе есть constraint , то будет полезна ссылка
http://www.postgresql.org/docs/7.4/static/catalog-pg-constraint.html


Я не играла со всеми системными таблицами, только с теми, которые мне нужны были для решения моих проф проблем, но я могу помочь с разборкой материала, со столбцами.
Вы читаете по-французски? Могу прислать мои примеры игры с системными таблицами

Что касатся pg_depend, для моих потребностей это была совершенно ненужная таблица.
Я не решаю Ваши задачи, даю наводку, Ваши потребности плохо очерчены в поставленной задаче, о какой зависимости Вы говорите? На фоне данного дока задавайте вопросы, если будут, я постараюсь просматривать эту тему

Поделитесь со сроками выполнения Вашего задания, можно делать срочно и плохо, и не очень быстро и намного лучше.

Что касается pgadmin, тоже решение, но какова верятность ошибки, на сколько хорошо можно восстановить структуру незнакомой БД, особенно если количество таблиц достаточно большое? Дело практики и опыта, но я считаю, что это не самый элегантный способ. Я уже не говорю, что связи между таблицами не исчерпываются только constraintами. Но, в самом деле, это - личное дело каждого.

Я написала сегодня уже один ответ, но только сейчас обнаружила, что он не отправился. Жалко, потому что теперь придется работать с моим примером. И у меня здесь нет под рукой постреса.
Мои таблицы:

-- Table: public."AchatsDetails"
CREATE TABLE "AchatsDetails" (
"N°Achat" int4 NOT NULL,
"N°Detail" int4 NOT NULL,
"DateDetail" date,
"Libelle" text,
"Quantite" float8,
CONSTRAINT "AchatsDetails_pkey"
PRIMARY KEY ("N°Achat", "N°Detail"),
CONSTRAINT "AchatsDetails_fk"
FOREIGN KEY ("N°Achat")
REFERENCES "Achats" ("N°Achat")
ON DELETE CASCADE ON UPDATE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE
) WITH OIDS;

-- Table: public."AchatsReceptions"
CREATE TABLE public."AchatsReceptions" (
"DateReception" date,
"Quantite" float8,

"N°thisDetail" int2 NOT NULL,
"N°thisAchat" int4 NOT NULL,

"N°Reception" int2 NOT NULL,
CONSTRAINT "AchatsReceptions_pkey"
PRIMARY KEY ("N°thisAchat", "N°thisDetail", "N°Reception"),
CONSTRAINT "AchatsReceptions_fk"
FOREIGN KEY ("N°thisAchat", "N°thisDetail")
REFERENCES "AchatsDetails" ("N°Achat", "N°Detail")
ON DELETE CASCADE ON UPDATE CASCADE NOT DEFERRABLE INITIALLY IMMEDIATE
) WITH OIDS;

Я делаю запрос:
tablefk - это таблица, которая содержит FOREIGN KEY, или REFERENCES.
В моем примере это - AchatsReceptions. В вашем примере, это таблица order_items.
reftable - это таблица, на которую(-ые) ссылаются. У меня - AchatsDetails.
У вас - products, orders.
conkey - массив номеров столбцов, отмеченных как PRIMARY KEY в таблице tablefk, которые ссылаются на PRIMARY KEY таблиц reftable. У меня эти столбцы в AchatsReceptions отмечены красным. И так "N°thisAchat" - 4, "N°thisDetail" - 3. У вас в order_items столбец product_no - 1, order_id - 2,
confkey - массив номеров столбцов, отмеченных как PRIMARY KEY в таблице reftable, которые являются FOREIGN KEY в таблице reftable и на которые ссылаются conkey. во выдала ...
У меня эти столбцы в AchatsDetails отмечены синим. И так "N°Achat" - 1, "N°Detail" - 2. У вас - orders.order_id - 1, products.product_no - 1.

Теперь WHERE:
1. По имени constraint в таблице tablefk
2. По имени tablefk
3. По имени reftable
Три варианта, что удобнее, только переставляете комментарий

SELECT
tablefkname.relname as tablefk,
pg_constraint.conkey,
reftablename.relname as reftable,
pg_constraint.confkey
FROM pg_constraint
INNER JOIN pg_class as tablefkname ON tablefkname.oid=pg_constraint.conrelid
INNER JOIN pg_class as reftablename ON reftablename.oid=pg_constraint.confrelid WHERE pg_constraint.conname='AchatsReceptions_fk'
-- WHERE tablefkname.relname='AchatsReceptions'
-- WHERE reftablename.relname='AchatsDetails'

ответ для моего примера:
tablefk : conkey :reftable : confkey
AchatsReceptions :{4,3} :AchatsDetails : {1,2}

для вашего пишу, не проверяя в постгресе
tablefk :conkey: reftable : confkey
order_items : {1} : product_no : {1}
order_items : {2} : orders : {1}
В массивах conkey и confkey очень важен порядок: conkey4 - confkey1,
conkey3 - confkey2.

Мой пример более сложный.
продолжение следует

Эгов, Putnikw
Вы попробывали то, что я вам предложила в сообщении 17 ноя 05, 22:12? Вам интересно это решение? Я просто не знаю, продолжать или нет? напишите мне, пожалуйста.

По вашему примеру
SELECT
tablefkname.relname as tablefk,
pg_constraint.conkey,
reftablename.relname as reftable,
pg_constraint.confkey
FROM pg_constraint
INNER JOIN pg_class as tablefkname ON tablefkname.oid=pg_constraint.conrelid
INNER JOIN pg_class as reftablename ON reftablename.oid=pg_constraint.confrelid

WHERE tablefkname.relname='order_items'

Естественно, вы можете использовать все системные таблицы из
http://www.postgresql.org/docs/7.4/static/catalogs.html
Начинать работать с ними трудно, потом становиться более понятно.

Одно очень важное замечание. Это не связано впрямую с вашей задачей, но в свое время мое невнимание на этот факт мне стоил дорого.
В системной таблице pg_attribute (stores information about table columns), есть столбец attisdropped (bool), объяснение в доке :
This column has been dropped and is no longer valid. A dropped column is still physically present in the table, but is ignored by the parser and so cannot be accessed via SQL.
Уничтоженный столбец никуда не исчезает, он становится просто недоступен для несистемный запросов, но у него существует свой порядковый номер. Таким образом, вы можете попасть, что у вас после 2-го столбца идет 4-ый: проверяйте всегда attisdropped = false при работе со столбцами.

И еще два запроса для поиска имен первичных и вторичный ключей:
--- SQL for PRIMARY KEY of table = pg_class.relname;
SELECT pg_constraint.conkey, pg_attribute.attname
FROM pg_constraint
INNER JOIN pg_attribute ON pg_constraint.conrelid=pg_attribute.attrelid
AND pg_attribute.attnum=ANY(pg_constraint.conkey)
INNER JOIN pg_class ON pg_constraint.conrelid=pg_class.oid
AND pg_constraint.contype='p'
AND pg_class.relkind='r'
AND pg_class.relname='order_items'

--- SQL for FOREIGN KEY of table=pg_class.relname
SELECT pg_class.relname, pg_constraint.conname,
pg_constraint.confkey, pg_attribute.attname
FROM pg_constraint
INNER JOIN pg_class ON pg_constraint.conrelid=pg_class.oid
AND pg_constraint.contype='f'
AND pg_class.relkind='r'
AND pg_class.relname='order_items'
INNER JOIN pg_attribute ON pg_constraint.confrelid=pg_attribute.attrelid
AND pg_attribute.attnum=ANY(pg_constraint.confkey)

Ну а теперь запрос для определения пользовательских таблиц БД.
pg_namespace.nspname - это имя схемы, где расположена база. У меня эта схема 'public':

SELECT *
FROM pg_class
INNER JOIN pg_namespace ON pg_class.relnamespace=pg_namespace.oid
WHERE relkind='r'
AND pg_namespace.nspname='public'

Чтобы просмотреть все схемы:
SELECT oid,* FROM pg_namespace

В принципе, это по-моему вся необходимая информация для решения вашей задачи. Было бы хорошо написать функцию, которая для каждой пользовательской таблицы выдавала бы PRIMARY KEY и FOREIGN KEY, да и другие данные, например inherits, если нужно.
У меня готовой такой функции нет, но если вас интересует, могу настучать