Rethinking sinval callback hook API

Currently, we have two types of callbacks that can be registered to get
control when an invalidation message is received: syscache callbacks and
relcache callbacks. It strikes me that we might be better advised to
unify these into a single type of callback that gets a
SharedInvalidationMessage struct pointer (we could pass NULL to signify
a cache reset event). That would avoid having to add another
registration list every time we decide that there's a reason for
callbacks to see another type of inval message. There are a couple of
reasonably near-term reasons why we might want to do this:

1. Robert was speculating the other day about wanting to be able to
snoop the inval traffic. Right now, callbacks can only snoop a fairly
small subset of it.

2. In conjunction with what I'm doing with plancache, it struck me that
it might be nice to subdivide relcache inval messages into two types,
one indicating a schema (DDL) change and one that just indicates that
statistics changed; this would allow us to avoid redoing parse analysis
and rewrite for a cached query as a consequence of autovacuum stats
updates. With the current scheme, plancache.c would need to register
two different kinds of callbacks to handle that, or we'd need some other
API change for relcache callbacks so they could distinguish.

A small disadvantage of this is that callbacks would have to know about
struct SharedInvalidationMessage, which right now isn't tremendously
widely known, but that doesn't seem like a fatal objection to me.
In practice that struct definition has been pretty stable.

Also, right now (9.2 cycle) would be a good time to do this since we
already changed the API for syscache callbacks as a result of my cache
bug investigations last week. Any third-party code that's hooking into
this area is going to need changes for 9.2 anyway.

Thoughts?

regards, tom lane