[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgis-users
Subject:    Re: [postgis-users] Re: Database design book recommendations for
From:       Martin Davis <mbdavis () refractions ! net>
Date:       2008-01-29 21:32:46
Message-ID: 479F9B7E.70309 () refractions ! net
[Download RAW message or body]


Chris Hermansen wrote:
> What do I mean by that?  Well, a table is a tuple of tuples, surely you
> could have a tuple of tuple of tuples, and you should be able to slice
> any of those (SELECT is a kind of slicing operation with a lot of
> features removed).
>   
Yes, would be nice.  The syntactical and semantic ramifications of this 
are potentially large, though, I think.  It would be nice to see a good 
design for a language working against this kind of model. 
>
>
> Again, maybe this is an implementation issue, but extensions are hard to
> do.  For instance, the whole PostGIS thing and that geometry_columns and
> spatial_ref_sys tables really ought to be system tables, and wouldn't it
> be nice when you CREATed a table containing geometry if there was
> something that would note this automagically and put corresponding info
> in the (system) geometry_columns table.  Not to mention a DROP TABLE
> statement that could be customized to unhook the geometry info...
>   
I see this as being orthogonal to SQL.  Maybe PostgreSQL needs to 
provide a more complete extension system, which allows extension-defined 
behaviour on DDL statements.
> Why is there not a standard for stored procedures to which database
> software designers adhere?  Same question for triggers.
>   
Or for that matter a standard SQL?  Oh - there is.  But vendors don't 
follow it, durn it.  Seems like this is a political issue, not a 
technical one.

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
[prev in list] [next in list] [prev in thread] [next in thread]