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

From Caleb Cushing
Subject Re: named generic constraints [feature request]
Date
Msg-id 81bfc67a0911230950v3a041f70p51ac32b39be21ebb@mail.gmail.com
Whole thread Raw
In response to Re: named generic constraints [feature request]  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: named generic constraints [feature request]
Re: named generic constraints [feature request]
List pgsql-hackers
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.

> 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: Teodor Sigaev
Date:
Subject: KNNGiST for knn-search
Next
From: Andrew Gierth
Date:
Subject: Re: [GENERAL] Updating column on row update