public inbox for [email protected]  

help / color / mirror / Atom feed

From: Vik Fearing <[email protected]>
To: Tom Lane <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Subject: Re: information_schema and not-null constraints
Date: Wed, 6 Sep 2023 04:31:44 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CAKFQuwZJmP3bTkc2dRYySy2XXDdxx-xzVQu3sGd8bRtg+GcYwA@mail.gmail.com>
	<[email protected]>
	<[email protected]>

On 9/6/23 02:53, Tom Lane wrote:
> Vik Fearing <[email protected]> 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

view thread (2+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: information_schema and not-null constraints
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox