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
