aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/misc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-02-02 17:11:55 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-02-02 17:11:55 -0500
commit62f34097c88433ef1f3de604714fe7e7024f2fdf (patch)
tree6bcedf1e516ad5ebfca4c93d94469ebf2733caf1 /src/backend/utils/adt/misc.c
parent479331406e8403cc2e75d1082f8c613e7669c113 (diff)
downloadpostgresql-62f34097c88433ef1f3de604714fe7e7024f2fdf.tar.gz
postgresql-62f34097c88433ef1f3de604714fe7e7024f2fdf.zip
Build in some knowledge about foreign-key relationships in the catalogs.
This follows in the spirit of commit dfb75e478, which created primary key and uniqueness constraints to improve the visibility of constraints imposed on the system catalogs. While our catalogs contain many foreign-key-like relationships, they don't quite follow SQL semantics, in that the convention for an omitted reference is to write zero not NULL. Plus, we have some cases in which there are arrays each of whose elements is supposed to be an FK reference; SQL has no way to model that. So we can't create actual foreign key constraints to describe the situation. Nonetheless, we can collect and use knowledge about these relationships. This patch therefore adds annotations to the catalog header files to declare foreign-key relationships. (The BKI_LOOKUP annotations cover simple cases, but we weren't previously distinguishing which such columns are allowed to contain zeroes; we also need new markings for multi-column FK references.) Then, Catalog.pm and genbki.pl are taught to collect this information into a table in a new generated header "system_fk_info.h". The only user of that at the moment is a new SQL function pg_get_catalog_foreign_keys(), which exposes the table to SQL. The oidjoins regression test is rewritten to use pg_get_catalog_foreign_keys() to find out which columns to check. Aside from removing the need for manual maintenance of that test script, this allows it to cover numerous relationships that were not checked by the old implementation based on findoidjoins. (As of this commit, 217 relationships are checked by the test, versus 181 before.) Discussion: https://postgr.es/m/3240355.1612129197@sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils/adt/misc.c')
-rw-r--r--src/backend/utils/adt/misc.c80
1 files changed, 80 insertions, 0 deletions
diff --git a/src/backend/utils/adt/misc.c b/src/backend/utils/adt/misc.c
index 4096faff9a1..634f574d7eb 100644
--- a/src/backend/utils/adt/misc.c
+++ b/src/backend/utils/adt/misc.c
@@ -25,6 +25,7 @@
#include "catalog/catalog.h"
#include "catalog/pg_tablespace.h"
#include "catalog/pg_type.h"
+#include "catalog/system_fk_info.h"
#include "commands/dbcommands.h"
#include "commands/tablespace.h"
#include "common/keywords.h"
@@ -37,6 +38,7 @@
#include "storage/fd.h"
#include "tcop/tcopprot.h"
#include "utils/builtins.h"
+#include "utils/fmgroids.h"
#include "utils/lsyscache.h"
#include "utils/ruleutils.h"
#include "utils/timestamp.h"
@@ -489,6 +491,84 @@ pg_get_keywords(PG_FUNCTION_ARGS)
}
+/* Function to return the list of catalog foreign key relationships */
+Datum
+pg_get_catalog_foreign_keys(PG_FUNCTION_ARGS)
+{
+ FuncCallContext *funcctx;
+ FmgrInfo *arrayinp;
+
+ if (SRF_IS_FIRSTCALL())
+ {
+ MemoryContext oldcontext;
+ TupleDesc tupdesc;
+
+ funcctx = SRF_FIRSTCALL_INIT();
+ oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
+
+ tupdesc = CreateTemplateTupleDesc(6);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 1, "fktable",
+ REGCLASSOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 2, "fkcols",
+ TEXTARRAYOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 3, "pktable",
+ REGCLASSOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 4, "pkcols",
+ TEXTARRAYOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 5, "is_array",
+ BOOLOID, -1, 0);
+ TupleDescInitEntry(tupdesc, (AttrNumber) 6, "is_opt",
+ BOOLOID, -1, 0);
+
+ funcctx->tuple_desc = BlessTupleDesc(tupdesc);
+
+ /*
+ * We use array_in to convert the C strings in sys_fk_relationships[]
+ * to text arrays. But we cannot use DirectFunctionCallN to call
+ * array_in, and it wouldn't be very efficient if we could. Fill an
+ * FmgrInfo to use for the call.
+ */
+ arrayinp = (FmgrInfo *) palloc(sizeof(FmgrInfo));
+ fmgr_info(F_ARRAY_IN, arrayinp);
+ funcctx->user_fctx = arrayinp;
+
+ MemoryContextSwitchTo(oldcontext);
+ }
+
+ funcctx = SRF_PERCALL_SETUP();
+ arrayinp = (FmgrInfo *) funcctx->user_fctx;
+
+ if (funcctx->call_cntr < lengthof(sys_fk_relationships))
+ {
+ const SysFKRelationship *fkrel = &sys_fk_relationships[funcctx->call_cntr];
+ Datum values[6];
+ bool nulls[6];
+ HeapTuple tuple;
+
+ memset(nulls, false, sizeof(nulls));
+
+ values[0] = ObjectIdGetDatum(fkrel->fk_table);
+ values[1] = FunctionCall3(arrayinp,
+ CStringGetDatum(fkrel->fk_columns),
+ ObjectIdGetDatum(TEXTOID),
+ Int32GetDatum(-1));
+ values[2] = ObjectIdGetDatum(fkrel->pk_table);
+ values[3] = FunctionCall3(arrayinp,
+ CStringGetDatum(fkrel->pk_columns),
+ ObjectIdGetDatum(TEXTOID),
+ Int32GetDatum(-1));
+ values[4] = BoolGetDatum(fkrel->is_array);
+ values[5] = BoolGetDatum(fkrel->is_opt);
+
+ tuple = heap_form_tuple(funcctx->tuple_desc, values, nulls);
+
+ SRF_RETURN_NEXT(funcctx, HeapTupleGetDatum(tuple));
+ }
+
+ SRF_RETURN_DONE(funcctx);
+}
+
+
/*
* Return the type of the argument.
*/