Re: Arrays and foreign keys - Mailing list pgsql-hackers

Don Baccus wrote:
> At 10:57 AM 8/10/00 +1000, Chris Bitmead wrote:
> >Stephan Szabo wrote:
> >> > This is an interesting point. Originally postgres integrity rules were
> >> > based on a very general rules system where many things were possible to
> >> > specify. I'm curious about the more recent addition of referential
> >> > integrity to postgres (I know little about it), why it is such a
> >> > specific solution and is not based on the more general postgres rules
> >> > system?
> >>
> >> Because unfortunately the SQL spec for referential integrity cannot really
> >> be implemented in the current rules system (or at least not in a way that
> >> is terribly nice).
> >
> >So it wasn't feasible to extend the current rules system to support
> >these oddities, instead of implementing the specific solution?
>
> Since Jan apparently knows more about the current rules system than anyone
> else on the planet (he's done a lot of work in that area in the past), and
> since he designed the RI system, my guess is that the simple answer to your
> question is "yes".
   "Yes"
   Rules  are  fired before the original query is executed. This   is because otherwise a DELETE (for example)  already
stamped   it's  XID and CID into the max fields of the tuples to delete   and the command counter gets incremented. So
therules  scans   would  never  be able to find them again. From the visibility   point of view they are deleted.
 
   To make rules deferrable in this visibility  system,  someone   would  need to remember the command ID of the
originalquery,   and when later executing the deferred queries modify all  the   scan-command  ID's  of  those
rangetable-entries,coming from   the original query, to have the original queries  CID,  while   leaving the others at
thecurrent.
 
   Theoretically  possible  up to here, but as soon as there are   any functions invoked in that query which use SPI,
it'sover.
 
   Finally  there  is  that problem about "triggered data change   violation".  Since only "changing the effective
value"of  an   FK or PK is considered to be a "data change", each individual   tuple must be checked for it. This
cannot be  told  on  the   query level.
 
   I'm  sure  it  cannot  be  done with the rule system. Thus we   created this "specific solution".
   And it is true that with the "very general rules  system"  of   the  "original  Postgres  4.2"  many things where
possibleto   specify. But most of them never worked  until  v6.4.  I  know   definitely,  because I found it out the
hardway - fixing it.   And still, many things don't work.
 
   Take some look at the short description of  the  rule  system   internals  in  the  programmers  guide. After that,
youmaybe   come to the same conclusions as I did. Otherwise  correct  me   by reimplementing SQL3 RI with rules.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #