W dniu 03.02.2015 o 04:44, Jim Nasby pisze:
On 1/3/15 2:49 AM, Rafal Pietrak wrote:
[---]
But an application could do
-a successfull scenario with expected result---
testvm=# UPDATE mailboxes SET username = null;
UPDATE 1
testvm=# DELETE FROM mail
On 1/3/15 2:49 AM, Rafal Pietrak wrote:
-test schema---
CREATE TABLE maildomains (domain text primary key, profile text not null);
CREATE TABLE mailusers (username text , domain text references
maildomains(domain) on update cascade, primary key (username, domain));
C
Alban Hertroys wrote:
> Unfortunately, I do not own a copy so I can't verify. If anyone
> who does own a copy could confirm or even quote the relevant
> section, that would be great.
I have a copy of The RELATIONAL MODEL for DATABASE MANAGEMENT,
VERSION 2 (RM/V2), by E. F. Codd, Copyright 1990,
> 1. I have a table with mailmessages, which has an FK to a table of hub users.
> 2. I'd like to retain the content of message repository (with it's domain key
> not cleared), when I drop a particular username from service to release
> that username to others.
> 3. I try to do that with FK "
> On Sun, 2015-01-25 at 14:09 +0100, Alban Hertroys wrote:
>
> The following link
>
> http://www.databaseanswers.org/codds_rules.htm
>
> sets out Ted Codd's rules according to C.J. Date.
As you might have noticed, those were referred to already upthread, but that is
a while ago now.
Although
On Sun, 2015-01-25 at 14:09 +0100, Alban Hertroys wrote:
> >> The theory got me intrigued. google
> >> (http://en.wikipedia.org/wiki/Codd%27s_12_rules) says:
> >> rule 3: "systematic treatment of null values"; hmmm this is a little
> >> broader then "support for null". I would think, that:
>> The theory got me intrigued. google
>> (http://en.wikipedia.org/wiki/Codd%27s_12_rules) says:
>> rule 3: "systematic treatment of null values"; hmmm this is a little
>> broader then "support for null". I would think, that:
>> 1. if a sequence of "update XX set fk_field=null; then delete Y
W dniu 04.01.2015 o 02:02, Alban Hertroys pisze:
[--]
"A table can have at most one primary key, but it may have more than one candidate
key. A primary key is a combination of columns which uniquely specify a row; it is a
special case of unique keys. One difference
> On 03 Jan 2015, at 23:14, Rafal Pietrak wrote:
>> Well, that’s embarrassing, it’s only a few weeks since I learned this and
>> I’m already attributing the theory to the wrong database deity! That’s
>> Codd-relationality, of course. Not Boyce.
>
> The theory got me intrigued. google
> (http:
A supporting view works OK.
-
CREATE VIEW api2users AS SELECT * from mailusers;
CREATE or replace RULE remove_user AS ON DELETE TO api2users do instead
(update mailboxes set username=null where username=old.username and
domain=old.domain; delete from mailusers where usern
> On 03 Jan 2015, at 18:05, Rafal Pietrak wrote:
> W dniu 03.01.2015 o 16:48, Alban Hertroys pisze:
>>> On 03 Jan 2015, at 15:20, Rafal Pietrak wrote:
>>>
> [-]
>>> Yes. This is precisely the "semantics" I'm trying to put into the schema:
>>> after a username is "releas
> On 03 Jan 2015, at 14:11, Alban Hertroys wrote:
>
> On 02 Jan 2015, at 13:31, Rafal Pietrak wrote:
>> Would it violate SQL standard (signifficantly), if an "on delete set null"
>> action just ignored all the FK columns that have a "NOT NULL" constraint set?
>
> As I understand it, this is p
On 01/03/2015 09:05 AM, Rafal Pietrak wrote:
W dniu 03.01.2015 o 16:48, Alban Hertroys pisze:
On 03 Jan 2015, at 15:20, Rafal Pietrak wrote:
[-]
Yes. This is precisely the "semantics" I'm trying to put into the
schema: after a username is "released" from service, all
W dniu 03.01.2015 o 16:48, Alban Hertroys pisze:
On 03 Jan 2015, at 15:20, Rafal Pietrak wrote:
[-]
Yes. This is precisely the "semantics" I'm trying to put into the schema: after a username is
"released" from service, all it's messages become "from unknown user"
> On 03 Jan 2015, at 15:20, Rafal Pietrak wrote:
>
> W dniu 03.01.2015 o 14:11, Alban Hertroys pisze:
> [--]
>> You assumed a functional dependency between username and domain, while those
>> fields actually describe independent entities that don’t necessarily go
>> together as
W dniu 03.01.2015 o 16:07, Adrian Klaver pisze:
On 01/03/2015 12:49 AM, Rafal Pietrak wrote:
[-]
With TRIGGER alone (i.e. without "documenting FK"), one will have to
analize the body of an "ever growing" function. Which at certain point
would become too much of an effort
On 01/03/2015 12:49 AM, Rafal Pietrak wrote:
W dniu 02.01.2015 o 20:37, Adrian Klaver pisze:
On 01/02/2015 08:55 AM, Rafal Pietrak wrote:
[--]
Is there a way to forcebly push the "old.username=null, throughout the
"on-update" FK chains into the all dependent tables, before co
W dniu 03.01.2015 o 14:11, Alban Hertroys pisze:
[--]
You assumed a functional dependency between username and domain, while those
fields actually describe independent entities that don’t necessarily go
together as you found out. Hence you need to normalise further.
For exampl
On 02 Jan 2015, at 13:31, Rafal Pietrak wrote:
>
> Hello,
>
> Rewriting my mail-hub I fell into the following problem:
> 1. I have a table with mailmessages, which has an FK to a table of hub users.
> 2. I'd like to retain the content of message repository (with it's domain key
> not cleared),
W dniu 02.01.2015 o 20:37, Adrian Klaver pisze:
On 01/02/2015 08:55 AM, Rafal Pietrak wrote:
[--]
Is there a way to forcebly push the "old.username=null, throughout the
"on-update" FK chains into the all dependent tables, before constraints
are checked for DELETE operation? I
On 01/02/2015 08:55 AM, Rafal Pietrak wrote:
W dniu 02.01.2015 o 17:05, Adrian Klaver pisze:
On 01/02/2015 07:45 AM, Rafal Pietrak wrote:
W dniu 02.01.2015 o 16:03, Adrian Klaver pisze:
On 01/02/2015 04:31 AM, Rafal Pietrak wrote:
[]
CCing the list.
Ups, sorry - no
W dniu 02.01.2015 o 17:05, Adrian Klaver pisze:
On 01/02/2015 07:45 AM, Rafal Pietrak wrote:
W dniu 02.01.2015 o 16:03, Adrian Klaver pisze:
On 01/02/2015 04:31 AM, Rafal Pietrak wrote:
[]
CCing the list.
Ups, sorry - not that button clicked.
[-
On 01/02/2015 07:45 AM, Rafal Pietrak wrote:
W dniu 02.01.2015 o 16:03, Adrian Klaver pisze:
On 01/02/2015 04:31 AM, Rafal Pietrak wrote:
[]
CCing the list.
Not sure about the standard, but pretty sure it will foul things up in
general. From the table structures abov
On 01/02/2015 04:31 AM, Rafal Pietrak wrote:
Hello,
Rewriting my mail-hub I fell into the following problem:
1. I have a table with mailmessages, which has an FK to a table of hub
users.
2. I'd like to retain the content of message repository (with it's
domain key not cleared), when I drop a par
Your main problem is that column "domain" of mailboxes is specified as NOT
NULL, so of course the "SET NULL" option will not work.
Here is the full message I see when I execute your code, which should
be self explanatory.
ERROR: null value in column "domain" violates not-null constraint
DETAIL:
Hello,
Rewriting my mail-hub I fell into the following problem:
1. I have a table with mailmessages, which has an FK to a table of hub
users.
2. I'd like to retain the content of message repository (with it's
domain key not cleared), when I drop a particular username from service
to relea
26 matches
Mail list logo
