postgresql/src/test/regress/expected/oidjoins.out

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

269 lines
15 KiB
Plaintext
Raw Normal View History

--
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
2021-02-02 23:11:55 +01:00
-- Verify system catalog foreign key relationships
--
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
2021-02-02 23:11:55 +01:00
DO $doblock$
declare
fk record;
nkeys integer;
cmd text;
err record;
begin
for fk in select * from pg_get_catalog_foreign_keys()
loop
raise notice 'checking % % => % %',
fk.fktable, fk.fkcols, fk.pktable, fk.pkcols;
nkeys := array_length(fk.fkcols, 1);
cmd := 'SELECT ctid';
for i in 1 .. nkeys loop
cmd := cmd || ', ' || quote_ident(fk.fkcols[i]);
end loop;
if fk.is_array then
cmd := cmd || ' FROM (SELECT ctid';
for i in 1 .. nkeys-1 loop
cmd := cmd || ', ' || quote_ident(fk.fkcols[i]);
end loop;
cmd := cmd || ', unnest(' || quote_ident(fk.fkcols[nkeys]);
cmd := cmd || ') as ' || quote_ident(fk.fkcols[nkeys]);
cmd := cmd || ' FROM ' || fk.fktable::text || ') fk WHERE ';
else
cmd := cmd || ' FROM ' || fk.fktable::text || ' fk WHERE ';
end if;
if fk.is_opt then
for i in 1 .. nkeys loop
cmd := cmd || quote_ident(fk.fkcols[i]) || ' != 0 AND ';
end loop;
end if;
cmd := cmd || 'NOT EXISTS(SELECT 1 FROM ' || fk.pktable::text || ' pk WHERE ';
for i in 1 .. nkeys loop
if i > 1 then cmd := cmd || ' AND '; end if;
cmd := cmd || 'pk.' || quote_ident(fk.pkcols[i]);
cmd := cmd || ' = fk.' || quote_ident(fk.fkcols[i]);
end loop;
cmd := cmd || ')';
-- raise notice 'cmd = %', cmd;
for err in execute cmd loop
raise warning 'FK VIOLATION IN %(%): %', fk.fktable, fk.fkcols, err;
end loop;
end loop;
end
$doblock$;
NOTICE: checking pg_proc {pronamespace} => pg_namespace {oid}
NOTICE: checking pg_proc {proowner} => pg_authid {oid}
NOTICE: checking pg_proc {prolang} => pg_language {oid}
NOTICE: checking pg_proc {provariadic} => pg_type {oid}
NOTICE: checking pg_proc {prosupport} => pg_proc {oid}
NOTICE: checking pg_proc {prorettype} => pg_type {oid}
NOTICE: checking pg_proc {proargtypes} => pg_type {oid}
NOTICE: checking pg_proc {proallargtypes} => pg_type {oid}
NOTICE: checking pg_proc {protrftypes} => pg_type {oid}
NOTICE: checking pg_type {typnamespace} => pg_namespace {oid}
NOTICE: checking pg_type {typowner} => pg_authid {oid}
NOTICE: checking pg_type {typrelid} => pg_class {oid}
NOTICE: checking pg_type {typsubscript} => pg_proc {oid}
NOTICE: checking pg_type {typelem} => pg_type {oid}
NOTICE: checking pg_type {typarray} => pg_type {oid}
NOTICE: checking pg_type {typinput} => pg_proc {oid}
NOTICE: checking pg_type {typoutput} => pg_proc {oid}
NOTICE: checking pg_type {typreceive} => pg_proc {oid}
NOTICE: checking pg_type {typsend} => pg_proc {oid}
NOTICE: checking pg_type {typmodin} => pg_proc {oid}
NOTICE: checking pg_type {typmodout} => pg_proc {oid}
NOTICE: checking pg_type {typanalyze} => pg_proc {oid}
NOTICE: checking pg_type {typbasetype} => pg_type {oid}
NOTICE: checking pg_type {typcollation} => pg_collation {oid}
NOTICE: checking pg_attribute {attrelid} => pg_class {oid}
NOTICE: checking pg_attribute {atttypid} => pg_type {oid}
NOTICE: checking pg_attribute {attcollation} => pg_collation {oid}
NOTICE: checking pg_class {relnamespace} => pg_namespace {oid}
NOTICE: checking pg_class {reltype} => pg_type {oid}
NOTICE: checking pg_class {reloftype} => pg_type {oid}
NOTICE: checking pg_class {relowner} => pg_authid {oid}
NOTICE: checking pg_class {relam} => pg_am {oid}
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
2021-02-02 23:11:55 +01:00
NOTICE: checking pg_class {reltablespace} => pg_tablespace {oid}
NOTICE: checking pg_class {reltoastrelid} => pg_class {oid}
NOTICE: checking pg_class {relrewrite} => pg_class {oid}
NOTICE: checking pg_attrdef {adrelid} => pg_class {oid}
NOTICE: checking pg_attrdef {adrelid,adnum} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_constraint {connamespace} => pg_namespace {oid}
NOTICE: checking pg_constraint {conrelid} => pg_class {oid}
NOTICE: checking pg_constraint {contypid} => pg_type {oid}
NOTICE: checking pg_constraint {conindid} => pg_class {oid}
NOTICE: checking pg_constraint {conparentid} => pg_constraint {oid}
NOTICE: checking pg_constraint {confrelid} => pg_class {oid}
NOTICE: checking pg_constraint {conpfeqop} => pg_operator {oid}
NOTICE: checking pg_constraint {conppeqop} => pg_operator {oid}
NOTICE: checking pg_constraint {conffeqop} => pg_operator {oid}
NOTICE: checking pg_constraint {conexclop} => pg_operator {oid}
NOTICE: checking pg_constraint {conrelid,conkey} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_constraint {confrelid,confkey} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_inherits {inhrelid} => pg_class {oid}
NOTICE: checking pg_inherits {inhparent} => pg_class {oid}
NOTICE: checking pg_index {indexrelid} => pg_class {oid}
NOTICE: checking pg_index {indrelid} => pg_class {oid}
NOTICE: checking pg_index {indcollation} => pg_collation {oid}
NOTICE: checking pg_index {indclass} => pg_opclass {oid}
NOTICE: checking pg_index {indrelid,indkey} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_operator {oprnamespace} => pg_namespace {oid}
NOTICE: checking pg_operator {oprowner} => pg_authid {oid}
NOTICE: checking pg_operator {oprleft} => pg_type {oid}
NOTICE: checking pg_operator {oprright} => pg_type {oid}
NOTICE: checking pg_operator {oprresult} => pg_type {oid}
NOTICE: checking pg_operator {oprcom} => pg_operator {oid}
NOTICE: checking pg_operator {oprnegate} => pg_operator {oid}
NOTICE: checking pg_operator {oprcode} => pg_proc {oid}
NOTICE: checking pg_operator {oprrest} => pg_proc {oid}
NOTICE: checking pg_operator {oprjoin} => pg_proc {oid}
NOTICE: checking pg_opfamily {opfmethod} => pg_am {oid}
NOTICE: checking pg_opfamily {opfnamespace} => pg_namespace {oid}
NOTICE: checking pg_opfamily {opfowner} => pg_authid {oid}
NOTICE: checking pg_opclass {opcmethod} => pg_am {oid}
NOTICE: checking pg_opclass {opcnamespace} => pg_namespace {oid}
NOTICE: checking pg_opclass {opcowner} => pg_authid {oid}
NOTICE: checking pg_opclass {opcfamily} => pg_opfamily {oid}
NOTICE: checking pg_opclass {opcintype} => pg_type {oid}
NOTICE: checking pg_opclass {opckeytype} => pg_type {oid}
NOTICE: checking pg_am {amhandler} => pg_proc {oid}
NOTICE: checking pg_amop {amopfamily} => pg_opfamily {oid}
NOTICE: checking pg_amop {amoplefttype} => pg_type {oid}
NOTICE: checking pg_amop {amoprighttype} => pg_type {oid}
NOTICE: checking pg_amop {amopopr} => pg_operator {oid}
NOTICE: checking pg_amop {amopmethod} => pg_am {oid}
NOTICE: checking pg_amop {amopsortfamily} => pg_opfamily {oid}
NOTICE: checking pg_amproc {amprocfamily} => pg_opfamily {oid}
NOTICE: checking pg_amproc {amproclefttype} => pg_type {oid}
NOTICE: checking pg_amproc {amprocrighttype} => pg_type {oid}
NOTICE: checking pg_amproc {amproc} => pg_proc {oid}
NOTICE: checking pg_language {lanowner} => pg_authid {oid}
NOTICE: checking pg_language {lanplcallfoid} => pg_proc {oid}
NOTICE: checking pg_language {laninline} => pg_proc {oid}
NOTICE: checking pg_language {lanvalidator} => pg_proc {oid}
NOTICE: checking pg_largeobject_metadata {lomowner} => pg_authid {oid}
NOTICE: checking pg_largeobject {loid} => pg_largeobject_metadata {oid}
NOTICE: checking pg_aggregate {aggfnoid} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggtransfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggfinalfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggcombinefn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggserialfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggdeserialfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggmtransfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggminvtransfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggmfinalfn} => pg_proc {oid}
NOTICE: checking pg_aggregate {aggsortop} => pg_operator {oid}
NOTICE: checking pg_aggregate {aggtranstype} => pg_type {oid}
NOTICE: checking pg_aggregate {aggmtranstype} => pg_type {oid}
NOTICE: checking pg_statistic {starelid} => pg_class {oid}
NOTICE: checking pg_statistic {staop1} => pg_operator {oid}
NOTICE: checking pg_statistic {staop2} => pg_operator {oid}
NOTICE: checking pg_statistic {staop3} => pg_operator {oid}
NOTICE: checking pg_statistic {staop4} => pg_operator {oid}
NOTICE: checking pg_statistic {staop5} => pg_operator {oid}
NOTICE: checking pg_statistic {stacoll1} => pg_collation {oid}
NOTICE: checking pg_statistic {stacoll2} => pg_collation {oid}
NOTICE: checking pg_statistic {stacoll3} => pg_collation {oid}
NOTICE: checking pg_statistic {stacoll4} => pg_collation {oid}
NOTICE: checking pg_statistic {stacoll5} => pg_collation {oid}
NOTICE: checking pg_statistic {starelid,staattnum} => pg_attribute {attrelid,attnum}
Extended statistics on expressions Allow defining extended statistics on expressions, not just just on simple column references. With this commit, expressions are supported by all existing extended statistics kinds, improving the same types of estimates. A simple example may look like this: CREATE TABLE t (a int); CREATE STATISTICS s ON mod(a,10), mod(a,20) FROM t; ANALYZE t; The collected statistics are useful e.g. to estimate queries with those expressions in WHERE or GROUP BY clauses: SELECT * FROM t WHERE mod(a,10) = 0 AND mod(a,20) = 0; SELECT 1 FROM t GROUP BY mod(a,10), mod(a,20); This introduces new internal statistics kind 'e' (expressions) which is built automatically when the statistics object definition includes any expressions. This represents single-expression statistics, as if there was an expression index (but without the index maintenance overhead). The statistics is stored in pg_statistics_ext_data as an array of composite types, which is possible thanks to 79f6a942bd. CREATE STATISTICS allows building statistics on a single expression, in which case in which case it's not possible to specify statistics kinds. A new system view pg_stats_ext_exprs can be used to display expression statistics, similarly to pg_stats and pg_stats_ext views. ALTER TABLE ... ALTER COLUMN ... TYPE now treats indexes the same way it treats indexes, i.e. it drops and recreates the statistics. This means all statistics are reset, and we no longer try to preserve at least the functional dependencies. This should not be a major issue in practice, as the functional dependencies actually rely on per-column statistics, which were always reset anyway. Author: Tomas Vondra Reviewed-by: Justin Pryzby, Dean Rasheed, Zhihong Yu Discussion: https://postgr.es/m/ad7891d2-e90c-b446-9fe2-7419143847d7%40enterprisedb.com
2021-03-26 23:22:01 +01:00
NOTICE: checking pg_statistic_ext {stxrelid} => pg_class {oid}
NOTICE: checking pg_statistic_ext {stxnamespace} => pg_namespace {oid}
NOTICE: checking pg_statistic_ext {stxowner} => pg_authid {oid}
NOTICE: checking pg_statistic_ext {stxrelid,stxkeys} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_statistic_ext_data {stxoid} => pg_statistic_ext {oid}
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
2021-02-02 23:11:55 +01:00
NOTICE: checking pg_rewrite {ev_class} => pg_class {oid}
NOTICE: checking pg_trigger {tgrelid} => pg_class {oid}
NOTICE: checking pg_trigger {tgparentid} => pg_trigger {oid}
NOTICE: checking pg_trigger {tgfoid} => pg_proc {oid}
NOTICE: checking pg_trigger {tgconstrrelid} => pg_class {oid}
NOTICE: checking pg_trigger {tgconstrindid} => pg_class {oid}
NOTICE: checking pg_trigger {tgconstraint} => pg_constraint {oid}
NOTICE: checking pg_trigger {tgrelid,tgattr} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_event_trigger {evtowner} => pg_authid {oid}
NOTICE: checking pg_event_trigger {evtfoid} => pg_proc {oid}
NOTICE: checking pg_description {classoid} => pg_class {oid}
NOTICE: checking pg_cast {castsource} => pg_type {oid}
NOTICE: checking pg_cast {casttarget} => pg_type {oid}
NOTICE: checking pg_cast {castfunc} => pg_proc {oid}
NOTICE: checking pg_enum {enumtypid} => pg_type {oid}
NOTICE: checking pg_namespace {nspowner} => pg_authid {oid}
NOTICE: checking pg_conversion {connamespace} => pg_namespace {oid}
NOTICE: checking pg_conversion {conowner} => pg_authid {oid}
NOTICE: checking pg_conversion {conproc} => pg_proc {oid}
NOTICE: checking pg_depend {classid} => pg_class {oid}
NOTICE: checking pg_depend {refclassid} => pg_class {oid}
NOTICE: checking pg_database {datdba} => pg_authid {oid}
NOTICE: checking pg_database {dattablespace} => pg_tablespace {oid}
NOTICE: checking pg_db_role_setting {setdatabase} => pg_database {oid}
NOTICE: checking pg_db_role_setting {setrole} => pg_authid {oid}
NOTICE: checking pg_tablespace {spcowner} => pg_authid {oid}
NOTICE: checking pg_auth_members {roleid} => pg_authid {oid}
NOTICE: checking pg_auth_members {member} => pg_authid {oid}
NOTICE: checking pg_auth_members {grantor} => pg_authid {oid}
NOTICE: checking pg_shdepend {dbid} => pg_database {oid}
NOTICE: checking pg_shdepend {classid} => pg_class {oid}
NOTICE: checking pg_shdepend {refclassid} => pg_class {oid}
NOTICE: checking pg_shdescription {classoid} => pg_class {oid}
NOTICE: checking pg_ts_config {cfgnamespace} => pg_namespace {oid}
NOTICE: checking pg_ts_config {cfgowner} => pg_authid {oid}
NOTICE: checking pg_ts_config {cfgparser} => pg_ts_parser {oid}
NOTICE: checking pg_ts_config_map {mapcfg} => pg_ts_config {oid}
NOTICE: checking pg_ts_config_map {mapdict} => pg_ts_dict {oid}
NOTICE: checking pg_ts_dict {dictnamespace} => pg_namespace {oid}
NOTICE: checking pg_ts_dict {dictowner} => pg_authid {oid}
NOTICE: checking pg_ts_dict {dicttemplate} => pg_ts_template {oid}
NOTICE: checking pg_ts_parser {prsnamespace} => pg_namespace {oid}
NOTICE: checking pg_ts_parser {prsstart} => pg_proc {oid}
NOTICE: checking pg_ts_parser {prstoken} => pg_proc {oid}
NOTICE: checking pg_ts_parser {prsend} => pg_proc {oid}
NOTICE: checking pg_ts_parser {prsheadline} => pg_proc {oid}
NOTICE: checking pg_ts_parser {prslextype} => pg_proc {oid}
NOTICE: checking pg_ts_template {tmplnamespace} => pg_namespace {oid}
NOTICE: checking pg_ts_template {tmplinit} => pg_proc {oid}
NOTICE: checking pg_ts_template {tmpllexize} => pg_proc {oid}
NOTICE: checking pg_extension {extowner} => pg_authid {oid}
NOTICE: checking pg_extension {extnamespace} => pg_namespace {oid}
NOTICE: checking pg_extension {extconfig} => pg_class {oid}
NOTICE: checking pg_foreign_data_wrapper {fdwowner} => pg_authid {oid}
NOTICE: checking pg_foreign_data_wrapper {fdwhandler} => pg_proc {oid}
NOTICE: checking pg_foreign_data_wrapper {fdwvalidator} => pg_proc {oid}
NOTICE: checking pg_foreign_server {srvowner} => pg_authid {oid}
NOTICE: checking pg_foreign_server {srvfdw} => pg_foreign_data_wrapper {oid}
NOTICE: checking pg_user_mapping {umuser} => pg_authid {oid}
NOTICE: checking pg_user_mapping {umserver} => pg_foreign_server {oid}
NOTICE: checking pg_foreign_table {ftrelid} => pg_class {oid}
NOTICE: checking pg_foreign_table {ftserver} => pg_foreign_server {oid}
NOTICE: checking pg_policy {polrelid} => pg_class {oid}
NOTICE: checking pg_policy {polroles} => pg_authid {oid}
NOTICE: checking pg_default_acl {defaclrole} => pg_authid {oid}
NOTICE: checking pg_default_acl {defaclnamespace} => pg_namespace {oid}
NOTICE: checking pg_init_privs {classoid} => pg_class {oid}
NOTICE: checking pg_seclabel {classoid} => pg_class {oid}
NOTICE: checking pg_shseclabel {classoid} => pg_class {oid}
NOTICE: checking pg_collation {collnamespace} => pg_namespace {oid}
NOTICE: checking pg_collation {collowner} => pg_authid {oid}
NOTICE: checking pg_partitioned_table {partrelid} => pg_class {oid}
NOTICE: checking pg_partitioned_table {partdefid} => pg_class {oid}
NOTICE: checking pg_partitioned_table {partclass} => pg_opclass {oid}
NOTICE: checking pg_partitioned_table {partcollation} => pg_collation {oid}
NOTICE: checking pg_partitioned_table {partrelid,partattrs} => pg_attribute {attrelid,attnum}
NOTICE: checking pg_range {rngtypid} => pg_type {oid}
NOTICE: checking pg_range {rngsubtype} => pg_type {oid}
NOTICE: checking pg_range {rngmultitypid} => pg_type {oid}
NOTICE: checking pg_range {rngcollation} => pg_collation {oid}
NOTICE: checking pg_range {rngsubopc} => pg_opclass {oid}
NOTICE: checking pg_range {rngcanonical} => pg_proc {oid}
NOTICE: checking pg_range {rngsubdiff} => pg_proc {oid}
NOTICE: checking pg_transform {trftype} => pg_type {oid}
NOTICE: checking pg_transform {trflang} => pg_language {oid}
NOTICE: checking pg_transform {trffromsql} => pg_proc {oid}
NOTICE: checking pg_transform {trftosql} => pg_proc {oid}
NOTICE: checking pg_sequence {seqrelid} => pg_class {oid}
NOTICE: checking pg_sequence {seqtypid} => pg_type {oid}
NOTICE: checking pg_publication {pubowner} => pg_authid {oid}
NOTICE: checking pg_publication_namespace {pnpubid} => pg_publication {oid}
NOTICE: checking pg_publication_namespace {pnnspid} => pg_namespace {oid}
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
2021-02-02 23:11:55 +01:00
NOTICE: checking pg_publication_rel {prpubid} => pg_publication {oid}
NOTICE: checking pg_publication_rel {prrelid} => pg_class {oid}
NOTICE: checking pg_subscription {subdbid} => pg_database {oid}
NOTICE: checking pg_subscription {subowner} => pg_authid {oid}
NOTICE: checking pg_subscription_rel {srsubid} => pg_subscription {oid}
NOTICE: checking pg_subscription_rel {srrelid} => pg_class {oid}