Re: information_schema and not-null constraints

On 9/6/23 02:53, Tom Lane wrote:
> Vik Fearing <vik(at)postgresfriends(dot)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