Opened 12 years ago

Last modified 11 years ago

#2217 closed defect

[raster] ST_Binary semantic discrepancy — at Initial Version

Reported by: mloskot Owned by: dustymugs
Priority: medium Milestone: PostGIS 2.1.0
Component: raster Version: master
Keywords: history Cc:

Description

Originally posted to postgis-devel in ST_Binary semantic thread, copied below.

Currently (SVN trunk), ST_Binary manifests dual nature, depending on in-db or out-db storage of raster data.

  • For in-db, ST_Binary returns complete blob with raster data in WKB format.
  • For out-db, ST_Binary returns the WKB header followed by local file path.

Assuming the WKB format is canonical representation, this ST_Binary manifests valid behaviour.

However, in the out-db case and from usability point of view, transporting local filesystem path does not make much sense.

I would argue, that canonical representation of WKB doesn't necessarily have to match ST_AsBinary output. It seems, currently we have made mistake in the fundamental behaviour.

Quick discussion with Regina, Sandro and Even on IRC confirms this argument is valid and common sense would suggest to most users that ST_Binary should output the same raster data, regardless storage mode on the server side.

Regina also commented that correction may or will potentially affect current users.

<robe2>proposal adversely affects prior backup and restore behavior
<robe2>Well the good thing is that I don't think too many people are
using out db in 2.0  (they might be using raster though).
2.1 has much more robust outdb
<robe2> So I think if we can catch it in 2.1 (even if it breaks 
out-db backward compatibility), it might be okay
<robe2> 3rd party readers are the MOST important folks to satisfy in my mind.
Because if you guys have difficulty supporting out of the box, no one will use it
<robe2> well GDAL a lot of third parties use indirectly so that goes without saying
<robe2> mloskot: anyrate like I said I think given we didn't really test 2.0 
out db and I have a feeling its pretty broken so as long as the change doesn't
affect in db, we'll be fine even if breaking for out db
<robe2> I mean in 2.1 (doing it in 2.1)

The choice between affecting current users of out-db raster storage (are there many?) and correcting API for correctness adn consistency in future uses is a difficult decision. Let's figure out how to handle it, please.

Change History (0)

Note: See TracTickets for help on using tickets.