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
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 |