| 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: | Whole Thread | Raw Message | 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 |