[raster] Inconsistent order of named args in ST_MapAlgebra

[robe]

You would only see this error in PostgreSQL 9.0. In PostgreSQL 8.4, it would just install the last one I think.

So the error I get is:

psql:share/contrib/postgis-2.0/rtpostgis.sql:1471: ERROR:  cannot change name of input parameter "pixeltype"
HINT:  Use DROP FUNCTION first.

The issue is your ST_MapAlgebra have arguments lists that are not in same order but have the same type. This is illegal in PostgreSQL 9.0+ because PostgreSQL 9.0+ supports named arguments

which means I can do ST_MapAlgebra(pixeltype:='8BUI',...) completely out of order. But since the way your functions are written could result in an ambiguous function path, your orders need to be the same. Sorry if I'm not making sense. --Any rate your issue is here. This is illegal in PostgreSQL 9.0+. I think you just need to swap the order of pixeltype and nodataexpress

-- This function can not be STRICT, because nodatavalueexpr can be NULL (could be just '' though)
-- or pixeltype can not be determined (could be st_bandpixeltype(raster, band) though)
CREATE OR REPLACE FUNCTION st_mapalgebra(rast raster, expression text,
        nodatavalueexpr text, pixeltype text)
    RETURNS raster
    AS $$ SELECT st_mapalgebra($1, 1, $2, $3, $4) $$
    LANGUAGE SQL;

-- This function can not be STRICT, because nodatavalueexpr can be NULL (could be just '' though)
CREATE OR REPLACE FUNCTION st_mapalgebra(rast raster, expression text,
        nodatavalueexpr text)
    RETURNS raster
    AS $$ SELECT st_mapalgebra($1, 1, $2, $3, NULL) $$
    LANGUAGE SQL;

[robe]

better yet use default args and then it will be a non-issue

[robe]

I think this may be related to #967 because as BBorie said, he was able to make check work cleanly on PostgreSQL 9.0+ by remarking out ST_MapAlgebra. That said, I consider this to be a blocker since it would prevent PostgreSQL 9.0+ from working in same fashion as PostgreSQL 8.4. I haven't tried that trick yet to confirm, but it fits the pattern.

[robe]

Guys -- can we please fix this one. Let me know if you want me to tackle it.

It's really hard to test when my 9.0 and 9.1 builds fail so miserably on the raster checks because of this problem.

[pracine]

Sure!

[robe]

okay will do then. Let me just finish compiling my 9.1 beta 2 first.

[robe]

fixed at r7397

[robe]

I didn't do #866 but is that just a renaming of the argument Pierre?

[pracine]

No, there are some changes to do in the functions as well.

[pracine]

I still get a problem with:

SELECT ST_Mapalgebra(ST_TestRaster(0, 0, 1), 'rast + 280'::text, '16BUI'::text)

which according to the doc should map to the third variant:

raster ST_MapAlgebra(raster rast, text expression, text pixeltype)

I get:

raster ST_MapAlgebra(raster rast, text expression, text pixeltype)
LINE 1: SELECT ST_Mapalgebra(ST_TestRaster(0, 0, 1), 'rast + 280'::t...
               ^
HINT:  Could not choose a best candidate function. You might need to add explicit type casts.

I'm (still) on PostgreSQL 8.4.1...

[pracine]

I think the solution would be to drop variant 2:

st_mapalgebra(rast raster, expression text, pixeltype text)

which is systematically in conflict with variant 3:

st_mapalgebra(rast raster, expression text, nodatavalueexpr text DEFAULT NULL, pixeltype text DEFAULT NULL)

robe?

[robe]

Pierre,

I'm all for dropping stuff :)

[pracine]

I removed (in r7662) this variant in the rtpostgis.sql:

st_mapalgebra(rast raster, expression text, pixeltype text)

Doc should follow...

[robe]

I think Pierre was waiting for me to document this before closing out. This ticket is now invalid anyway since we no longer has a function called ST_MapAlgebra.