Re: information_schema and not-null constraints

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