id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc 2200,"[raster] [raster] ST_Union(rast, uniontype) should be deprecated or support multiple bands",robe,Bborie Park,"I was all about to put in an enhancement ticket because of my experience with #2199 until I realized my big beef is with ST_Union(rast,uniontype). The other functions behave as expected without explanation: e.g. they either take the band they specify or they take all bands. so my proposal is to either mark ST_Union(rast, uniontype) as deprecated and remove it from description as at top (just remove the proto from our documentation) or have it take all bands. The reason I say this is I realized, if I wanted to work with multiple bands, I'd do this: {{{ (WITH mset AS ( SELECT ROW_NUMBER() OVER() As rnum, rast FROM (SELECT ST_Tile(rast, (ST_Width(rast))::integer/2, ST_Height(rast)/2) As rast FROM (SELECT ST_Resize(rast,0.10,0.10) As rast FROM pics WHERE filename='Mona_Lisa.jpg' LIMIT 1) As foo ) As foofoo ) SELECT ST_Union(ST_SetUpperLeft(rast,ST_UpperLeftX(rast)*-1,ST_UpperLeftY(rast)*-1) , ARRAY[ROW(1, 'MEAN'), ROW(2, 'MEAN'), ROW(3, 'MEAN')]::unionarg[] ) FROM mset where rnum IN(1,2)) }}} And that works as expected -- working with all bands and if I had multiple bands -- I would assume as I did in #2199 and be sorely disappointed. I think we also neglected to mention unionarg variant is a new variant in 2.1. I'll update the docs for that one. So why do I want to get rid of ST_Union(rast,uniontype) -- because it violates the principle of least surprise and its yet another proto to remember that forces me to write the word EXCEPT. Note: I'm not proposing we remove it because all those 1 band folks might be using it. Just suggesting we don't document it and if we do keep document it (and not deprecate it), change it to behave like the other functions so it does not violate the principle of least surprise. ",enhancement,closed,medium,PostGIS 2.1.0,raster,master,fixed,history,