--
From: Alban Hertroys [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 4:15 AM
To: Robert Haas
Cc: David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Robert Haas wrote:
> I don't understand what a weighted constraint wo
Robert Haas wrote:
> I sort of think that this kind of stuff belongs in a separate table
> somehow. For example in this case I would want to:
I wasn't suggesting otherwise. A constraint is a constraint; whether it
involves an extra table or not wasn't really relevant until now
(apparently).
> CR
Robert Haas wrote:
> I don't understand what a weighted constraint would mean. Either the
> attacker_id can be a wolf, or it can't. Knowing that it is only 1%
> likely over the long haul is insufficient to disallow any particular
> transaction.
Basically I suggested to combine the constraint wit
2007 4:02 AM
To: Robert Haas
Cc: David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Robert Haas wrote:
> The idea here is that a wolf can attack a sheep, or a wolf can attack
> another wolf, but sheep can't attack anything. I s
: Alban Hertroys
Cc: Robert Haas; David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Alban Hertroys wrote:
> Robert Haas wrote:
> > The idea here is that a wolf can attack a sheep, or a wolf can
attack
> > another wolf, but she
to attack eachother.
>
> Depending on what you're modelling, even this could be too simple -- for
> example, while a single wolf is unlikely to attack a lion, a pack of
> wolves have a lot more probability of doing so.
>
> Do you keep packs of wolves in your barn? If so, watch your lions.
Well
On Fri, Feb 23, 2007 at 09:39:52AM -0500, Robert Haas wrote:
> Actually, what would be really nice is if there were just a button I
> could push that would make all of my data automatically correct.
> Can that go into 8.3? Thanks, ...Robert
Oh, no problem. Just compile with -ldwim ;)
Cheers,
D
On Fri, 23 Feb 2007, Joris Dobbelsteen wrote:
> >-Original Message-
> >From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> >Sent: vrijdag 23 februari 2007 9:50
> >To: Joris Dobbelsteen
> >Cc: pgsql-general@postgresql.org
> >Subject: Re: [GE
>-Original Message-
>From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
>Sent: vrijdag 23 februari 2007 9:50
>To: Joris Dobbelsteen
>Cc: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] complex referential integrity constraints
>
>On Fri, Feb 23, 2007 at
Alban Hertroys wrote:
> Robert Haas wrote:
> > The idea here is that a wolf can attack a sheep, or a wolf can attack
> > another wolf, but sheep can't attack anything. I suppose I could list
> > each wolf in both the predator and prey tables, but that seems a bit
> > duplicative (and causes other
Robert Haas wrote:
> The idea here is that a wolf can attack a sheep, or a wolf can attack
> another wolf, but sheep can't attack anything. I suppose I could list
> each wolf in both the predator and prey tables, but that seems a bit
> duplicative (and causes other problems).
>
> ...Robert
I'm q
On Fri, Feb 23, 2007 at 12:41:25AM +0100, Joris Dobbelsteen wrote:
> >Reasonably. I have no idea what visibility rules would make
> >any difference at all. AIUI a foreign key just takes a shared
> >lock on the referenced row and all the magic of MVCC makes
> >sure the row exists when the transac
>-Original Message-
>From: Stephan Szabo [mailto:[EMAIL PROTECTED]
>Sent: donderdag 22 februari 2007 23:13
>To: Joris Dobbelsteen
>Cc: Martijn van Oosterhout; Robert Haas; pgsql-general@postgresql.org
>Subject: Re: [GENERAL] complex referential integrity constraints
>
>-Original Message-
>From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
>Sent: donderdag 22 februari 2007 23:15
>To: Joris Dobbelsteen
>Cc: Robert Haas; pgsql-general@postgresql.org
>Subject: Re: [GENERAL] complex referential integrity constraints
>
>On Thu, Fe
neral@postgresql.org
Subject: RE: [GENERAL] complex referential integrity constraints
>Why don't you add a field in animal_types that is boolean mauler.
>Then you can add a trigger on the mauling table to raise an
>error when the attacker_id is an animal type mauler.
This is only
From: David Fetter [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 1:04 PM
To: Robert Haas
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
On Fri, Feb 16, 2007 at 09:58:56AM -0500, Robert Haas wrote:
> So, I have the following
it would be.
Still, I'd love to see it in the TODO file, too.
...Robert
-Original Message-
From: Joris Dobbelsteen [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 8:03 AM
To: Robert Haas; elein
Cc: pgsql-general@postgresql.org
Subject: RE: [GENERAL] complex referential inte
On Thu, Feb 22, 2007 at 06:51:49PM +0100, Joris Dobbelsteen wrote:
> >Err, foreign keys are implemented using triggers, so this
> >statement is self-contradictary.
>
> Are you really sure they are executed under the same visibility rules?
Reasonably. I have no idea what visibility rules would ma
s; pgsql-general@postgresql.org
> >Subject: Re: [GENERAL] complex referential integrity constraints
> >
> >On Thu, Feb 22, 2007 at 05:28:35PM +0100, Joris Dobbelsteen wrote:
> >> Even worse, I don't you can guarentee that this constraint
> >is enforced
> >
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Martijn van Oosterhout
>Sent: donderdag 22 februari 2007 18:17
>To: Joris Dobbelsteen
>Cc: Robert Haas; pgsql-general@postgresql.org
>Subject: Re: [GENERAL] complex referenti
On Thu, Feb 22, 2007 at 05:28:35PM +0100, Joris Dobbelsteen wrote:
> Even worse, I don't you can guarentee that this constraint is enforced
> at all times. That means, not if you are using triggers.
> The only option seems using foreign keys and put in a lot of redundant
> data.
Err, foreign keys
>-Original Message-
>From: Robert Haas [mailto:[EMAIL PROTECTED]
>Sent: donderdag 22 februari 2007 15:58
>To: Joris Dobbelsteen; elein
>Cc: pgsql-general@postgresql.org
>Subject: RE: [GENERAL] complex referential integrity constraints
>
>The ability to make a
2007 3:37
>To: Joris Dobbelsteen; elein
>Cc: pgsql-general@postgresql.org
>Subject: RE: [GENERAL] complex referential integrity constraints
>
>Yes, exactly. And while you might not care about all of those
>(e.g. I care about the first two but am not worried about the
>third one becaus
On Mon, Feb 19, 2007 at 10:52:51AM -0800, Richard Broersma Jr wrote:
> > I'd do something like this:
> >
> > CREATE TABLE animal_type (
> > animal_name TEXT PRIMARY KEY,
> > CHECK(animal_name = trim(animal_name))
> > );
> >
> > /* Only one of {Wolf,wolf} can be in the table. */
> >
> >
> I'd do something like this:
>
> CREATE TABLE animal_type (
> animal_name TEXT PRIMARY KEY,
> CHECK(animal_name = trim(animal_name))
> );
>
> /* Only one of {Wolf,wolf} can be in the table. */
>
> CREATE UNIQUE INDEX just_one_animal_name
> ON animal_type(LOWER(animal_name));
>
> C
On Fri, Feb 16, 2007 at 09:58:56AM -0500, Robert Haas wrote:
> So, I have the following problem.
>
> Suppose you have two kinds of animals, sheep and wolves. Since they
> have very similar properties, you create a single table to hold both
> kinds of animals, and an animal_type table to specify t
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of elein
>Sent: zondag 18 februari 2007 23:16
>To: Robert Haas
>Cc: pgsql-general@postgresql.org
>Subject: Re: [GENERAL] complex referential integrity constraints
>
>On Fri, Feb 1
Robert Haas wrote:
> So, I have the following problem.
>
> Suppose you have two kinds of animals, sheep and wolves. Since they
> have very similar properties, you create a single table to hold both
> kinds of animals, and an animal_type table to specify the type of each
> animal:
>
> CREATE TABL
On Fri, Feb 16, 2007 at 09:58:56AM -0500, Robert Haas wrote:
> So, I have the following problem.
>
> Suppose you have two kinds of animals, sheep and wolves. Since they
> have very similar properties, you create a single table to hold both
> kinds of animals, and an animal_type table to specify t
"Robert Haas" <[EMAIL PROTECTED]> writes:
> ... The problem with this is that I have a very unsettled feeling about the
> foreign key constraints on this table. The victim_id constraint is
> fine, but the attacker_id constraint is really inadequate, because the
> attacker CAN NEVER BE A SHEEP.
I
So, I have the following problem.
Suppose you have two kinds of animals, sheep and wolves. Since they
have very similar properties, you create a single table to hold both
kinds of animals, and an animal_type table to specify the type of each
animal:
CREATE TABLE animal_type (
id
31 matches
Mail list logo
