[Resent: mailing list only]
Tom, you mail server won't accept:
The e-mail system was unable to deliver the message, but did not report
a specific reason.  Check the address and try again.  If it still fails,
contact your system administrator.
< orange.nl #5.0.0 X-SMTP-Server; host sss.pgh.pa.us[]
said: 550    5.0.0 Go away, spammer (in reply to MAIL FROM command)>

>-----Original Message-----
>From: Tom Lane [mailto:[EMAIL PROTECTED] 
>Sent: maandag 26 maart 2007 19:52
>To: Joris Dobbelsteen
>Cc: pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Guarenteeing complex referencial 
>integrity through custom triggers 
>"Joris Dobbelsteen" <[EMAIL PROTECTED]> writes:
>> My intention is to expose the functionality to the outside world for 
>> general use. This provides means to ensure custom complex 
>> can be enforced properly. I hope to push it into 8.3 if possible.
>You are at least a month too late for 8.3, even if you had a 
>solid design now, which you clearly don't. 

Than its not possible, next try later on. I was messing up different
dates it seemed.

>Nor am I convinced 
>that we really want/need to support what you are talking about 
>at the SQL level.  To me, the crosscheck stuff in the RI 
>support is an extremely dirty hack that might or might not be 
>100% correct.  Exposing it to the SQL level, and thereby 
>committing to support it forever, seems the height of folly.


Yet I see several options:
1) Extend the approach taken for the current RI triggers (i.e.
'cross-check hack').
2) Build some general framework for constraint enforcement.
3) Invent something new.
[Few more that aren't really proposable]

At this point:
1) At least Tom's not in favor and there is little commerical motivation
to do it right.
2) This is extremely huge project and needs to build on a primitive,
with the current only a 'dirty hack' available. Probably it extends the
CHECK syntax currently supported, and this is extremely involved.
3) Falling short of the innovative/sparkling idea.

The case is that at this point consistency within a single modified
snapshot of the database, does not imply all possible views (snapshots)
are consistent too. So we need to ensure both are consistent. Yet there
is no single _supported_ way to make that work. Its falling short on its
commercial competitors (and my view of an 'enterprise dbms'

I'm fully open to other suggestions...

- Joris

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to