On Tue, Mar 06, 2012 at 04:27:11PM -0500, Tom Lane wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > On Tue, Mar 06, 2012 at 11:10:38AM -0500, Tom Lane wrote:
> >> Why would you need to know that? The reason the calculation function
> >> is static is that there's no apparent need to expose that information
> >> outside the syscache subsystem.
>
> > Because I need to invalidate my own internal state that corresponds
> > to particular system catalog row?
>
> > In current case (plproxy) I need to invalidate libpq connections
> > that are created from particular foreign server entry.
>
> [ shrug... ] You could just flush 'em all, which is what most existing
> inval callbacks do. Admittedly a libpq connection is a bit more
> expensive than the average bit of invalidatable state, but how often
> does pg_foreign_server get updated?
The frequency does not matter, it's the impact of what happens
when it does get updated. There may be many connections.
> Or you could do like setrefs.c does, and assume you know how to
> calculate the hash value for an OID-keyed cache.
Ok, the hashoid() hack works. But please take it as report from
the ground that this API is useful outside of core and it would
be good if it stays useful.
--
marko
