[derefr]

> Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine.

You could just as well say that multi-text-encoding sort/group collation, compound keys, or, for that matter, indexes on anything other than primary keys, are "application-specific function[s] that shouldn't be bloating a database engine"--and then go back to using BerkeleyDB.

The point of relational databases is not data warehousing, nor is it to batch-execute preprogrammed queries on extremely-denormalized data at hyperspeed (that's what NoSQL and all that other noise is about.) The niche RDBMSes fill, is that they provide an abstraction layer for doing unforeseen data analysis using arbitrary relational projections and selections while the database remains online, without having to worry about (or modify!) the underlying data-structures. "SELECT user_id WHERE ST_Distance(location, my_house) < 100 AND has_beer = TRUE" is a perfectly sensible question to ask of any database that stores locations of things (and whether they have beer), whether or not that's part of the application that put the data there.

[DavidAbrams]

OK, then why shouldn't there be a special function to assess the cost of the beer in any specified currency at the time of the query?

Should there be special functions for querying the characteristics of JPEGs stored as BLOBs? How about PNGs?

Where does this end? Just because a couple of float values happen to represent latitude and longitude doesn't mean the DB engine should integrate geospatial logic.

[dickeytk]

except it doesn't, it's an optional extension

[DavidAbrams]

And yet conveniently cited as a feature of the database engine when it suits you.

[derefr]

> Where does this end?

With Erlang QLCs :)