[raster] ST_MapAlgebraExpr : do not convert expression to uppercase

[strk]

Converting the expression to uppercase breaks it. I'm trying to execute reprojections within the expression, and proj4 doesn't accept '+PROJ=LATLON' nicely...

[pracine]

Probably we can search for 'rast' in a non case sensitive way instead of converting the expression to uppercase.

[Bborie Park]

I've made the appropriate changes for 2-raster ST_MapAlgebraExpr to be case-sensitive. So the keywords are now RAST1 and RAST2. Committed is r8999.

[pracine]

So if I write 'rast2 + rast1' it does not work anymore?

[Bborie Park]

Correct. We could support both upper and lower case.

[strk]

Since things are moving, could we also protect the keywords a bit more ? So that it is less likely that your expression wants to use the "rast" substring in the name of a function or a table or a column ?

Also, since I added "rast.x" and "rast.y", could the current "rast" also become "rast.val" and unify the set of keywords in both 1-raster and 2-raster versions ? Like for 2-rasters could be "rast.x", "rast.y", "rast.val1", "rast.val2"

[Bborie Park]

I wish you hadn't added "rast.x" and "rast.y" before everyone had a chance to agree to the keywords to be added and their definitions.

[pracine]

And it would not be "rast.val1", "rast.val2" but "rast1.val", "rast2.val"...

And if the two rasters are not aligned there is no reason that rast1.x is equal to rast2.x so we would need the two names.

[strk]

@dustymugs, nothing is set in stones, 2.0 isn't out yet. @pracine: I wasn't thinking about the unalignment, so right, could be the index is always in the rast part.

[Bborie Park]

Since we're changing and adding the keywords used, we might as well create another ticket to decide on the keywords and leave this ticket exclusively for preventing the conversion of the expressions to upper-case.

[strk]

Fixed in r9031