Обсуждение: CHECK NO INHERIT syntax
Sorry to raise this once again, but I still find this CHECK NO INHERIT syntax to a bit funny. We are currently using something like CHECK NO INHERIT (foo > 0) But we already have a different syntax for attaching attributes to constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more sense to have CHECK (foo > 0) NO INHERIT Besides consistency, this makes more sense, because the attribute is a property of the constraint as a whole, not of the "checking". This would also extend more easily to other constraint types. For example, when unifying CHECK and NOT NULL constraints, as is planned, or when allowing inherited unique constraints, as is planned further down the road. There is also a hole in the current implementation. Domain constraints silently allow NO INHERIT to be specified, even though other senseless attributes are rejected.
On Wed, Jul 18, 2012 at 5:49 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > Sorry to raise this once again, but I still find this CHECK NO INHERIT > syntax to a bit funny. We are currently using something like > > CHECK NO INHERIT (foo > 0) > > But we already have a different syntax for attaching attributes to > constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more > sense to have > > CHECK (foo > 0) NO INHERIT > > Besides consistency, this makes more sense, because the attribute is a > property of the constraint as a whole, not of the "checking". > > This would also extend more easily to other constraint types. For > example, when unifying CHECK and NOT NULL constraints, as is planned, or > when allowing inherited unique constraints, as is planned further down > the road. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jul 19, 2012 at 12:49:37AM +0300, Peter Eisentraut wrote: > Sorry to raise this once again, but I still find this CHECK NO INHERIT > syntax to a bit funny. We are currently using something like > > CHECK NO INHERIT (foo > 0) > > But we already have a different syntax for attaching attributes to > constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more > sense to have > > CHECK (foo > 0) NO INHERIT How about this? CHECK (foo > 0) (INHERIT FALSE) That leaves an obvious place for other options, which will doubtless come. EXPLAIN's options inspired this API design. > Besides consistency, this makes more sense, because the attribute is a > property of the constraint as a whole, not of the "checking". Good point. The above change preserves this property. > This would also extend more easily to other constraint types. For > example, when unifying CHECK and NOT NULL constraints, as is > planned, or when allowing inherited unique constraints, as is > planned further down the road. > > There is also a hole in the current implementation. Domain > constraints silently allow NO INHERIT to be specified, even though > other senseless attributes are rejected. That's probably a bug. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> On Thu, Jul 19, 2012 at 12:49:37AM +0300, Peter Eisentraut wrote:
>> But we already have a different syntax for attaching attributes to
>> constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more
>> sense to have
>>
>> CHECK (foo > 0) NO INHERIT
> How about this?
> CHECK (foo > 0) (INHERIT FALSE)
The SQL spec already says what the syntax is for options attached to
constraints, and that's not it.
regards, tom lane
Excerpts from Peter Eisentraut's message of mié jul 18 17:49:37 -0400 2012: > Sorry to raise this once again, but I still find this CHECK NO INHERIT > syntax to a bit funny. We are currently using something like > > CHECK NO INHERIT (foo > 0) > > But we already have a different syntax for attaching attributes to > constraints (NOT DEFERRABLE, NOT VALID, etc.), so it would make more > sense to have > > CHECK (foo > 0) NO INHERIT Okay, given the astounding acceptance of your proposal, the attached patch fixes things in that way. This only include changes to the core code; I'll prepare documentation and regression tests tweaks while I wait for an answer to the request below. > There is also a hole in the current implementation. Domain constraints > silently allow NO INHERIT to be specified, even though other senseless > attributes are rejected. True. I have added an error check at creation time. Please suggest improved wording for the message: alvherre=# create domain positiveint2 as int check (value > 0) no inherit; ERROR: CHECK constraints for domains cannot be NO INHERIT -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Вложения
Alvaro Herrera <alvherre@commandprompt.com> writes:
> True. I have added an error check at creation time. Please suggest
> improved wording for the message:
> alvherre=# create domain positiveint2 as int check (value > 0) no inherit;
> ERROR: CHECK constraints for domains cannot be NO INHERIT
I think "CHECK constraints for domains cannot be marked NO INHERIT"
would be fine.
> ConstraintElem:
> - CHECK opt_no_inherit '(' a_expr ')' ConstraintAttributeSpec
> + CHECK '(' a_expr ')' opt_no_inherit ConstraintAttributeSpec
This doesn't seem to me to meet the principle of least surprise. Surely
NO INHERIT ought to be folded into ConstraintAttributeSpec so that it
acts like other constraint decorations, ie order isn't significant.
regards, tom lane
Excerpts from Tom Lane's message of vie jul 20 16:12:05 -0400 2012:
>
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > True. I have added an error check at creation time. Please suggest
> > improved wording for the message:
>
> > alvherre=# create domain positiveint2 as int check (value > 0) no inherit;
> > ERROR: CHECK constraints for domains cannot be NO INHERIT
>
> I think "CHECK constraints for domains cannot be marked NO INHERIT"
> would be fine.
Thanks.
> > ConstraintElem:
> > - CHECK opt_no_inherit '(' a_expr ')' ConstraintAttributeSpec
> > + CHECK '(' a_expr ')' opt_no_inherit ConstraintAttributeSpec
>
> This doesn't seem to me to meet the principle of least surprise. Surely
> NO INHERIT ought to be folded into ConstraintAttributeSpec so that it
> acts like other constraint decorations, ie order isn't significant.
Oh, true; that's a bit more involved. I verified it works correctly to
have a constraint marked NOT VALID NO INHERIT or the other way around.
I haven't checked whether the changes to ConstraintAttributeSpec have
side effects -- I think it's OK but I might be missing something.
Here's a (hopefully) complete patch.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Вложения
Excerpts from Alvaro Herrera's message of sáb jul 21 00:20:57 -0400 2012: > Here's a (hopefully) complete patch. Pushed. I hope people like this one better (third time's the charm, and all that). -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support