Re: Recording foreign key relationships for the system catalogs

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: "Peter Eisentraut" <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Recording foreign key relationships for the system catalogs
Date: 2021-02-01 19:33:26
Message-ID: fc795777-c40a-45f1-bb95-281b8e74c14e@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi again,

After trying to use pg_get_catalog_foreign_keys() to replace what I had before,
I notice one ambiguity which I think is a serious problem in the machine-readable context.

The is_array OUT parameter doesn't say which of the possibly many fkcols that is the array column.

One example:

fktable | fkcols | pktable | pkcols | is_array
----------------------+-----------------------+--------------+-------------------+----------
pg_constraint | {conrelid,conkey} | pg_attribute | {attrelid,attnum} | t

Is the array "conrelid" or is it "conkey"? As a human, I know it's "conkey", but for a machine to figure out, one would need to join information_schema.columns and check the data_type or something similar.

Suggestions on how to fix:

* Make is_array an boolean[], and let each element represent the is_array value for each fkcols element.

* Change interface to be more like information_schema, and add a "ordinal_position" column, and return each column on a separate row.

I think I prefer the latter since it's more information_schema-conformant, but any works.

/Joel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-02-01 19:47:34 Re: Recording foreign key relationships for the system catalogs
Previous Message Euler Taveira 2021-02-01 19:11:50 Re: row filtering for logical replication