Kevin Grittner wrote: > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote:
> > 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. > > What are you saying is unacceptable, and what behavior would be > acceptable instead?
The answer "we don't support the situation where you have an index using an IMMUTABLE function that isn't actually immutable" is not acceptable. The acceptable solution would be a design that doesn't have that property as a requisite.
Yes, a much better solution would be for PostgreSQL to examine the body of every function and determine on its own the proper volatility - or lacking that to "sandbox" (for lack of a better term) function execution so it simply cannot do things that conflict with its user specified marking. But the prevailing opinion on this list is that such an effort is not worthy of resources and that "let the user keep both pieces"
is the more expedient policy. That this patch is being defended using that argument is consistent to policy and thus quite acceptable.
The technical details here are just beyond my reach ATM but I think Robert's meta-points are spot on. Though to be fair we are changing a fundamental assumption underlying how the system and transactions operate - the amount of code whose assumptions are now being stressed is non-trivial; and for a feature that will generally have less use in production - and likely in much higher-stakes arenas - having a professionally hostile approach will help to ensure that what is released has been thoroughly vetted.
These edge cases should be thought of, discussed, and ideally documented somewhere so that future coders can see and understand that said edges have been considered even if the answer is: "well, we don't blow up and at worse have some slightly off statistics, that seems fine".
