[postgis-devel] [PostGIS] #1319: [raster] Make raster_columns a constraint-based view, replace AddRasterColumn with AddRasterConstraints and expand # of constraints on raster columns

[PostGIS]

#1319: [raster] Make raster_columns a constraint-based view, replace
AddRasterColumn with AddRasterConstraints and expand # of constraints on
raster columns
----------------------------+-----------------------------------------------
 Reporter:  robe            |       Owner:  dustymugs    
     Type:  task            |      Status:  assigned     
 Priority:  critical        |   Milestone:  PostGIS 2.0.0
Component:  postgis raster  |     Version:  trunk        
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by mloskot):

 Replying to [comment:39 dustymugs]:
 > Replying to [comment:37 mloskot]:
 > > Please, with all my respect, don't be scientific-ignorant here guys
 and don't make PostGIS Raster just another GRASS, please.
 >
 > scientific-ignorant?  You'll have to elaborate on that.

 I have a constant impression that the PostGIS Raster is becoming more
 fully-featured analytical GIS system where storage use cases are
 forgotten.
 I apologies if I've touched you or anyone.

 > > If you decide to get rid of this flag, then the only way to determine
 if a table is tiles storage or not is to perform slow (!) query.
 > >
 >
 > From the looks of it in the AddRasterColumn function, regular_blocking
 is just a boolean value passed with no true validation of making sure
 > that no tiles overlap and there are no gaps.  As the appropriate
 constraints won't be added until after PostGIS 2.0 is released, we could
 just
 > add a garbage constraint to indicate that a column is regularly blocked.

 AFAIR, constraint on regular blocking has never been planned. It would be
 slow anyway.
 The uploader is supposed to play the key role here and take care of
 assuring tiles in a table are regularly
 blocked if such configuration is requested.
 IMHO, the fact that there is no constraint attached does not make the flag
 useless or invalid concept.

 > > Per analogia, where vector folks here store SRID information?
 >
 > You're going to have to be more descriptive here.

 Nevermind, this is wrong analogy.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1319#comment:42>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.