Re: BUG #12869: PostGIS 2.2 can't compile against 9.5 dev branch

>While I trust your judgement actual knowledge is nice. The fact that PostGIS is raising the complaint should make us rethink those assumptions; and nothing in their code or the minimal
> example strikes me as being improper. That said, I am surprised you didn't recommend that the function should be moved to a FROM clause - though I believe the code could still optimize > that way without the offset 0.

> The PostGIS example involves constructing geometries from a definition. I suspect that is not cheap, which suggests that maybe we could recommend increasing the cost of the function above
> the default and refusing to flatten a function if the cost is sufficiently high?

Guys I tried increasing cost with the ST_Reclass function to 2000 and it didn't help. The function is called for every single output. The only thing that helps is setting this to VOLATILE as Tom suggests. I guess we can do that as some sort of fix for these kinds of functions though I'm not sure if that would cause other issues.

> As for claiming that this is broken and should be reverted: nyet. In the
> first place, there is certainly no PG documentation anywhere that promises
> single evaluation of a function written in the manner shown here.

> But what does the typical user expect? That should be the digested standard: whether it is documented should be secondary. It is not documented that the given query will be multiply

> evaluated either - and the fact that the query, as written, only include the function call once would suggest the user expect that it will only be evaluated once,

A good chunk of PostGIS functions are very costly and return a raster, geometry, geography object which is then further acted on in queries. As David noted, the general user -- partly because of observation I guess assumed the behavior that a function such as that would only be called once. I suppose if we were to change all such things to VOLATILE, that would be fine, but I'm concerned about the vast number of PostGIS users who further wrap the PostGIS functions and don't know to do this.

> I cannot help but feel there is a patch here that allows us to negate the regression while keeping the benefits - but it's beyond my skills to prove that let alone write it.

> David J.

Does this change affect any function that takes a complex object and then has that complex object return another complex object? If that is the case, this would be disastrous for PostGIS users upgrading to 9.5 unless we change all the functions we have that have this behavior to VOLATILE. I would be okay with that as long as it doesn't cause performance issues for older versions of PostgreSQL and doesn't cause performance issues elsewhere.

Thanks,
Regina