Re: Eliminating SPI from RI triggers - take 2

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... I think there's some
> debate to be had here over what behavior we need to preserve exactly
> vs. what we can and should change.

For sure. For example, people occasionally complain because
user-defined triggers can defeat RI integrity checks. Should we
change that? I dunno, but if we're not using the standard executor
then there's at least some room to consider it. I think people would
be upset if we stopped firing user triggers at all; but if triggers
couldn't defeat RI actions short of throwing a transaction-aborting
error, I believe a lot of people would consider that an improvement.

> For instance, it seems clear to me
> that leaving out permissions checks altogether would be not OK, but if
> this implementation arranged to cache the results of a permission
> check and the SQL-based implementations don't, is that OK? Maybe Tom
> would argue that it isn't, because he considers that a part of the
> user-visible behavior, but I'm not sure that's the right view of it.

Uh ... if such caching behavior is at all competently implemented,
it will be transparent because the cache will notice and respond to
events that should change its outputs. So I don't foresee a semantic
problem there. It may well be that it's practical to cache
permissions-check info for RI checks when it isn't for more general
queries, so looking into ideas like that seems well within scope here.
(Or then again, maybe we should be building a more general permissions
cache?)

I'm too tired to have more than that to say right now, but I agree
that there is room for discussion about exactly what behavior we
want to preserve.

regards, tom lane