Re: named generic constraints [feature request] - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: named generic constraints [feature request]
Date
Msg-id 162867790911231039rb2cd625m928f3915eeb5668@mail.gmail.com
Whole thread Raw
In response to Re: named generic constraints [feature request]  (Caleb Cushing <xenoterracide@gmail.com>)
List pgsql-hackers
2009/11/23 Caleb Cushing <xenoterracide@gmail.com>:
> On Mon, Nov 23, 2009 at 4:17 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Hello
>>
>> do you know domains? It is very similar to your proposal.
>>
>
> obviously since I cited it.
>
>> constraint cannot be  part of  expression.
>>
> why not? NOT NULL is a contraint, UNIQUE is a contstraint.

yes - but you are defined constraint empty - not "not empty". for
example - there are not a constraint "NOT UNIQUE". I thing, so this
isn't workable. Constrainst are hard coded - it uses keywords. Your
new syntax is redundant - there are not any special value to using
CHECK clause and functions.

Regards
Pavel Stehule

>
>> CREATE OR REPLACE FUNCTION emptystr(text)
>> RETURNS bool AS $$
>>  SELECT $1 <> ''; -- it is SQL not C
>> $$ LANGUAGE sql;
>>
>> CREATE TABLE users(
>>  username TEXT CHECK (NOT emptystr(username)),
>>  ...
>
> this is probably the 'best' current solution.  however, I'd like to be
> able to not have to name the column for every constraint. and domains
> only seem right if it's something, like a zip code, that has a very
> specific set of rules, that is in reality it's own type. where
> specifying something like 'empty' feels as generic (and arbitrary?) as
> null. empty is not the only example (I'm sure), just the best I can
> think of.
>
>> p.s. Is it related to ANSI SQL?
>
> not to my knowledge (can't say that it isn't though, I've never read
> the standard).
> --
> Caleb Cushing
>
> http://xenoterracide.blogspot.com
>


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: EXPLAIN BUFFERS
Next
From: Alexey Klyukin
Date:
Subject: arrays as input parameters in plperl