[postgis-devel] What to return when refering to an invalid band number

[Paragon Corporation]

> I also tend to disagree...

> Regina do you see cases when it is preferable to return just a warning and
a null instead of an error? Is there any rule about that in PostGIS?

I think it depends on the severity of the issue.  If its something that is
expected with normal data then it returns NULL or warning.  If it's a case
that should never ever happen, then it should return an error  (like your
disk is out of disk space - would be wrong to return NULL :) ).

But that also varies in degree.  For the ST_Value guess, I would say NULL is
better, as if I happened not to do an ST_Intersects check, for whatever
reason, I woudn't want the query to blow up


> -You are making a query that takes hours and, for a million of possible
reasons, only one row or a few rows store data having a smaller range than
the provided index. You don't want your query to stop with an error. You
just want a warning and a null result helping you to find the black sheep.
You might find out that the black sheep is normal and you are happy that you
got all the other results.

> Think about this kind of query as a batch program. What a frustration when
your 4 hours batch stop with an error instead of just a log of something
wrong and the rest totally normal... You have to launch it again taking care
of this spefific case even if it might be normal.

Yes indeed very frustrating -- I think of those GEOS topology exception
errors that drive me crazy and usually for stuff I don't care about breaks
my whole query.  Then again some people may care and notices are too easy to
ignore.  It would be ideal to have a flag option either as another argument
or as GUC that defines whether you care or not.

> -Right now we return just a warning and a null when the x and y of
ST_Value(rast, band, x, y) are out of range. I don't remember the exact
cases but I know in many situations this much more convenient.
Yes much more convenrient

>  We must not thing about SQL queries the same way we thing about C or
Python functions. The fact that SQL queries apply to many different data,
might takes hours and are often done by humans makes them very different. It
seems to me...
True but then again there are certain cases where you want the whole batch
to fail and we must not forget about that either.

Thanks,
Regina