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
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
