Kevin Grittner wrote:
> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> > The expression index case is the one to worry about; if there is a
> > problem, that's where it is. What bothers me is that a function used
> > in an expression index could do anything at all - it can read any
> > table in the database.
>
> It *can*, but then you are lying to the database when you call it
> IMMUTABLE. Such an index can easily become corrupted through
> normal DML. Without DML the ANALYZE has no problem. So you seem
> to be concerned that if someone is lying to the database engine to
> force it accept a function as IMMUTABLE when it actually isn't, and
> then updating the referenced rows (which is very likely to render
> the index corrupted), that statistics might also become stale.
We actually go quite some lengths to support this case, even when it's
the opinion of many that we shouldn't. For example VACUUM doesn't try
to find index entries using the values in each deleted tuple; instead we
remember the TIDs and then scan the indexes (possibly many times) to
find entries that match those TIDs -- which is much slower. Yet we do
it this way to protect the case that somebody is doing the
not-really-IMMUTABLE function.
In other words, I don't think we consider the position you argued as
acceptable.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
