Re: check problem

tks for answering.
Identity is the private key from the table. using your examples you could
have :
1) ident1,1,'aaaa'
2) ident2,1,'aaaa'
3) ident3,2,'aaaa'
4) ident4,3,'bbbb'

but not

5)identi5,1,'bbbb'

-->same implicit_group for different privates.
is it possible? tks again

>From: Michael Fuhr <mike(at)fuhr(dot)org>
>To: Luis Silva <lfs12(at)hotmail(dot)com>
>CC: pgsql-novice(at)postgresql(dot)org
>Subject: Re: [NOVICE] check problem
>Date: Thu, 23 Feb 2006 15:45:23 -0700
>
>On Thu, Feb 23, 2006 at 06:54:49PM +0000, Luis Silva wrote:
> > I there. I having a problem. I have a table with 3 columns, identity,
> > implicit_group(int) and private. if insert, for exemple, one identity
>with
> > an implicit_group with the value '1' and a private 'aaaa' i need to
> > guaranty that i can't insert another identity with an implicity_group
>'1'
> > and a different private. How can I do this? tks a lot.
>
>It's not clear exactly what you want to allow and prevent. Is it
>acceptable to insert a different identity with the same implicit_group
>and private as the first row? What about another row with the same
>identity as the first row but with a different implicit_group and/or
>private? It might be helpful if you could indicate whether each
>of the following rows, inserted in the given order, should be
>accepted or rejected and why:
>
>1) 'ident1', 1, 'aaaa' -- first row, assumed to be accepted
>2) 'ident1', 1, 'aaaa' -- duplicate of (1)
>3) 'ident1', 1, 'bbbb' -- same ident and group as (1) but different
>private
>4) 'ident1', 2, 'aaaa' -- same ident and private as (1) but different
>group
>5) 'ident1', 2, 'bbbb' -- same ident as (1) but different group and
>private
>6) 'ident2', 1, 'aaaa' -- different ident as (1) but same group and
>private
>7) 'ident2', 1, 'bbbb' -- different ident and private as (1) but same
>group
>8) 'ident2', 2, 'aaaa' -- different ident and group as (1) but same
>private
>9) 'ident2', 2, 'bbbb' -- different ident, group, and private from (1)
>
>It might also be helpful if you gave an abstract explanation of the
>problem you're trying to solve. Sometimes that can suggest a schema
>redesign.
>
>--
>Michael Fuhr
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: Don't 'kill -9' the postmaster