[postgis-devel] RE: WKTRaster news from the Toronto CodeSprint?

[Frank Warmerdam]

Stephen Frost wrote:
> I don't believe we've answered the question of if raster_columns could
> be a view yet.  That's why I was asking after what the columns of the
> table were, and I don't feel comfortable yet that I've gotten an answer
> to that.  The spec seemed to include things that wouldn't go in the
> table..
> 
> Certainly, I believe it would ideally be a view which lived in
> pg_catalog to make it nice and transparent to the user.  One of my big
> beefs with the current setup is the (ab)use of the public schema with an
> assumption that it'll always be in a users search_path (which is just
> flat-out wrong alot of the time for things I'm doing..).
> 
> Another big frustration point is having to use functions to add geometry
> columns, and having to hand-update the tables for things like views that
> have geometry columns in them.  Now that user typmods are a reality in
> PG, we should really be looking to use them as much as possible.  That
> would greatly improve the experience for PG admins who do things like
> pg_dump individual schemas (w/o dumping the public schema, or even
> wanting to reload the whole geometry_columns table..), create views,
> etc.
> 
>> I've personally given up on the "making it a view" aspect, but there
>> may be ways of mitigating other negative aspects of it.  I am just
>> not clear on what the issue(s) are.
> 
> What is your concern about making these views?  Honestly, in the worst
> case we'd have to do something like have a side-table that just creates
> an ID for each new set of options given with the parameters similar to
> the current tables and then have the view based on that.  At least for
> users it would still be transparent since you can tailor the
> input/output for the typmod to be something like:
> 
> mycolumn    geometry(4269,'POINT',2)

Stephen,

I'm afraid I'm way out of my depth here.  I was told there were only
32bits of information to hold information beyond what would be available
from other sources (I assumed this was the normal column definition info
in the catalogs), and this clearly was not enough for stuff like a 2D
double precision extent so I just wrote off the issue.

I understand a simple metadata table maintained by applications or
supporting functions. I read what you wrote above, but I have no clue
what you are talking about.  I don't mind it being a view as long as
I can have the various bits of info I want, and as long as it is reasonably
straight forward how I would update stuff (for an application library like
GDAL for instance), and as long as it being a view isn't going to make it
slow to access.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent