On 9/6/23 02:53, Tom Lane wrote:
Vik Fearing <v...@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



Reply via email to