On Sun, Jan 17, 2021, at 18:16, Tom Lane wrote:
> I kind of wonder whether findoidjoins has outlived its purpose and
> we should just remove it (along with the oidjoins test script).
A bit of background:
I'm working on an extension where I need SQL access to this reference information.
My extension is successfully automatically helping me to find problems in extension update-scripts,
where an update from a version to a version would give a different result than directly installing the to-version from scratch.
Currently, I'm parsing findoidjoins/README and importing the "from column" and "to column"
to a lookup-table, which is used by my extension.
If findoidjoins is removed, I would be happy as long as this reference information
continues to be provided in some other simple machine-readable way,
like a CSV-file somewhere in the repo, or even better: making this information
available from SQL via a new lookup-table in pg_catalog.
I can see how parsing catalogs.sgml would be doable,
but proper SGML parsing is quite complex since it's a recursive language,
and can't be reliably parsed with e.g. simple regexes.
So I think adding this as a lookup table in pg_catalog is the best solution,
since extension writers could then use this information in various ways.
The information is theoretically already available via catalogs.sgml,
but a) it's not easy to parse, and b) it's not available from SQL.
Are there any other hackers who ever wished they would have had SQL
access to these catalog references?
If desired by enough others, perhaps something along these lines could work?
CREATE TABLE pg_catalog.pg_references (
colfrom text,
colto text,
UNIQUE (colfrom)
);
Where "colfrom" would be e.g. "pg_catalog.pg_class.relfilenode"
and "colto" would be "pg_catalog.pg_class.oid" for that example.
Not sure about the column names "colfrom"/"colto" though,
since the abbreviation for columns seems to be "att" in the pg_catalog context.
/Joel
