Comment 6 for bug 1253163

Good find, as usual, Dan!

So, indeed, it's the fact that we're lying to PG that is causing the pain. I'm surprised that the index in question is being consulted during the select that claims to fail, but that is really beside the point. I can't find a single smoking gun in the release notes, and the changelog for 9.3 is, um, long, but I suspect that a combination of visibility map changes and general index infrastructure improvements lead to a situation where PG needs to be able to trust our promises more than in the past.

If it's an open question as to whether we should address the underlying lie directly -- and I think it's pretty well answered by Tom Lane's response to the poster of a similar issue on the Pg bugs list -- I'm strongly inclined to spend the disk space on materialized, indexable values, else eventually we'll run afoul of this or something very much like it in the future.

The immutability of that function exists solely to allow it to be used in an index expression, so dropping that and calling it STABLE instead seems correct. Adding STRICT would be correct, too, as there's no reasonable non-NULL output for NULL input.

As for the situation when authority config is modified -- that's something we certainly need to discuss, but on another bug, I think. It's is related not only to heading definition changes, but to authority merge (and the associated timeouts) and, more broadly, reingest of both authority and bib data, due to schema or config changes, or batch updates. I sketched a couple ideas over on bug 1193490, but here and now is probably not the time to address that larger challenge...