Estou tentando obter uma lista de restrições de chave estrangeira no seguinte formulário:
pk_table | pk_col | fk_table | fk_col
sem usar pg_get_constraintdef
(o que me forçaria a recorrer à manipulação de strings).
Existe alguma razão pela qual a consulta a seguir não funciona?
SELECT
x.conname,
x.contype,
x.conrelid,
x.confrelid,
pk.tablename,
fk.tablename
FROM pg_catalog.pg_constraint x
INNER JOIN pg_catalog.pg_tables pk ON x.conrelid!=0 AND x.conrelid=(pk.tablename :: regclass :: oid)
INNER JOIN pg_catalog.pg_tables fk ON x.confrelid!=0 AND x.confrelid=(fk.tablename :: regclass :: oid)
WHERE
x.connamespace in (SELECT oid FROM pg_catalog.pg_namespace n WHERE n.nspname in ('b2b', 'public'))
AND x.contype='f'
Erro:
ERROR: relation "sql_implementation_info" does not exist
Minha hipótese era que o PG está ficando confuso devido à presença de vários namespaces, então tentei restringir o conjunto de resultados aos meus esquemas conhecidos, ou seja b2b, public
, , mas isso ainda não funciona.
O problema é que nem todas as "tabelas" apresentadas na
pg_tables
view foramOID
apresentadas napg_class
relação:Você deve reescrever sua consulta para mais "baixo nível":
test
Eu consultei um banco de dados vazio e sua consulta estava bem:
No entanto, quando criei duas tabelas com uma chave estrangeira:
Eu obtive o seguinte:
No começo eu pensei que era um problema com o meu usuário, mas recebi o mesmo erro ao sudo para o psql.
Então comecei a investigar o catálogo no postgres, e acho que você deve estar bem com informações de constraint_column_usage e information_schema.table_constraints
Não tenho certeza exatamente o que sua consulta deve retornar, então vou deixá-la lá.
Não sei se há alguma desvantagem usando information_schema vs pg_catalog (suponho que algumas coisas específicas do psql não estejam em information_schema), mas o information_schema se parece muito com information_schemas em outros DBMS:s. Portanto, se você conhece o information_schema no psql, deve ser capaz de usar esse conhecimento em outros DBMS.