[postgis-devel] Deprecate ST_MapAlgebraExpr and ST_MapAlgebraFct

[Pierre Racine]

> > Speed is not always the deciding feature...
> >
> You may come to regret those words... ;-)

I always prefer things that save me time over things that save computer time. For sure I prefer those that can do both, but if you think about how things were slow just some years ago. Imagine if someone would have said "we should not do it because it's too slow"... There would be no car, no internet, not many things actually. We would still be in prehistoric ages... I will never regret offering more functionality.

> > That means no support for people not comfortable with writing a custom
> function...
> >
> 
> True.  But maybe they just needed a reason to get into writing their own
> functions.  Just like users of MS Excel or any stats software end up
> having to write their own functions...

Will be easier for them to say: let's use ArcGIS instead... Am I the only one working with non programmers here? I get plenty of people here able to write SQL statements but not able to write SQL functions. That another level of abstraction. You want your nice statement to be faster, now you have to learn how to write a plpgsql function...
 
> 2. user defined expressions are always a security weakness (SQL
> injection) and there is no way we can say that this is impossible.

You are writing SQL, how can you inject SQL when you are writing SQL? It's like if you would say, there might be some C injection in my C code. Not much sense... 

> 3. expressions only work in the simplest of cases.  How many keywords do
> you need for handing a set of 5x5 neighborhoods from 5 input rasters?
> That would mean 125 parameters to substitute, not to count X,Y pixel
> positions from each input rasters and output raster.

AFAIK there is no such thing as a neighborhood variant working with expressions. There are only custom function neighborhood ones because, as you mention, handling neighbor is far more complex then handling one pixel at a time.

> Basic tools should always be available in the API with some "generic"
> advanced tools being provided for use in more specific applications.

What would that look like?

I strongly suggest we keep the two expression variants. They work very well and make life easier in many situations.

Pierre