Horton

Re: information_schema and not-null constraints

Vik Fearing <vik@postgresfriends.org>

View thread
From: Vik Fearing <vik@postgresfriends.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Peter Eisentraut <peter@eisentraut.org>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2023-09-06T02:31:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert structural changes to not-null constraints

  2. Fix inconsistencies in error messages

  3. Disallow direct change of NO INHERIT of not-null constraints

  4. Disallow NO INHERIT not-null constraints on partitioned tables

  5. Better handle indirect constraint drops

  6. Don't try to assign smart names to constraints

  7. Fix restore of not-null constraints with inheritance

  8. ATTACH PARTITION: Don't match a PK with a UNIQUE constraint

  9. Fix propagating attnotnull in multiple inheritance

  10. Check stack depth in new recursive functions

  11. Move privilege check to the right place

  12. Update information_schema definition for not-null constraints

  13. Fix not-null constraint test

  14. Disallow changing NO INHERIT status of a not-null constraint

  15. Catalog not-null constraints

  16. parallel_schedule: add comment on event_trigger test dependency

  17. Revert "Catalog NOT NULL constraints" and fallout

  18. Adjust contrib/sepgsql regression test expected outputs.

  19. Fix table name clash in recently introduced test

  20. Catalog NOT NULL constraints

  21. Change the rules for inherited CHECK constraints to be essentially the same

On 9/6/23 02:53, Tom Lane wrote:
> Vik Fearing <vik@postgresfriends.org> writes:
>> On 9/6/23 00:14, David G. Johnston wrote:
>>> I'm not all that for either A or B since the status quo seems workable.
> 
>> Pray tell, how is it workable?  The view does not identify a specific
>> constraint because we don't obey the rules on one side and we do obey
>> the rules on the other side.  It is completely useless and unworkable.
> 
> What solution do you propose?  Starting to enforce the spec's rather
> arbitrary requirement that constraint names be unique per-schema is
> a complete nonstarter.  Changing the set of columns in a spec-defined
> view is also a nonstarter, or at least we've always taken it as such.

I both semi-agree and semi-disagree that these are nonstarters.  One of 
them has to give.

> If you'd like to see some forward progress in this area, maybe you
> could lobby the SQL committee to make constraint names unique per-table
> not per-schema, and then make the information_schema changes that would
> be required to support that.

I could easily do that; but now you are asking to denormalize the 
standard, because the constraints could be from tables, domains, or 
assertions.

I don't think that will go over well, starting with my own opinion.

And for this reason, I do not believe that this is a "rather arbitrary 
requirement".

> In general though, the fact that we have any DDL extensions at all
> compared to the standard means that there will be Postgres databases
> that are not adequately represented by the information_schema views.

Sure.

> I'm not sure it's worth being more outraged about constraint names
> than anything else.  Or do you also want us to rip out (for starters)
> unique indexes on expressions, or unique partial indexes?

Indexes of any kind are not part of the standard so these examples are 
basically invalid.

SQL:2023-11 Schemata is not the part I am most familiar with, but I 
don't even see where regular multi-column unique constraints are listed 
out, so that is both a lack in the standard and a knockdown of this 
argument.  I am happy to be shown wrong about this.
-- 
Vik Fearing