On 2023-Sep-05, Peter Eisentraut wrote: > The following information schema views are affected by the not-null > constraint catalog entries: > > 1. CHECK_CONSTRAINTS > 2. CONSTRAINT_COLUMN_USAGE > 3. DOMAIN_CONSTRAINTS > 4. TABLE_CONSTRAINTS > > Note that 1 and 3 also contain domain constraints.
After looking at what happens for domain constraints in older versions (I tested 15, but I suppose this applies everywhere), I notice that we don't seem to handle them anywhere that I can see. My quick exercise is just create domain nnint as int not null; create table foo (a nnint); and then verify that this constraint shows nowhere -- it's not in DOMAIN_CONSTRAINTS for starters, which is I think the most obvious place. And nothing is shown in CHECK_CONSTRAINTS nor TABLE_CONSTRAINTS either. This did ever work in the past? I tested with 9.3 and didn't see anything there either. I am hesitant to try to add domain not-null constraint support to information_schema in the same commit as these changes. I think this should be fixed separately. (Note that if, in older versions, you change the table to be create table foo (a nnint NOT NULL); then you do get a row in table_constraints, but nothing in check_constraints. With my proposed definition this constraint appears in check_constraints, table_constraints and constraint_column_usage.) On 2023-Sep-04, Tom Lane wrote: > I object very very strongly to this proposed test method. It > completely undoes the work I did in v15 (cc50080a8 and related) > to make the core regression test scripts mostly independent of each > other. Even without considering the use-case of running a subset of > the tests, the new test's expected output will constantly be needing > updates as side effects of unrelated changes. You're absolutely right, this would be disastrous. A better alternative is that the new test file creates a few objects for itself, either by using a separate role or by using a separate schema, and we examine the information_schema display for those objects only. Then it'll be better isolated. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ Subversion to GIT: the shortest path to happiness I've ever heard of (Alexey Klyukin)