[DavidAbrams]

The article's arguments aren't that convincing. Geospatial indexing? That's an application-specific function that shouldn't be bloating a database engine. If anything, the grocery list of crap mentioned by this article makes me DOUBT Postgres's focus on being an efficient database.

The other problem is that every host offers MySQL. Not so with Postgres.

[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 :)

[masklinn]

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

GIS most certainly belongs in the database. You don't want to load gigabytes of geo data as points in memory and build and filter geometries in whatever your application is, anymore than you want to load any non-trivial dataset in-memory and do your filtering in your application language.

[blutonium]

Yeah, that's why they're supported in PostgreSQL, MySQL, Oracle, DB2, MSSQL, even SQLite... Multi-dimensional data isn't restricted to the world of GIS, and B-Trees are not up to the task.

[DavidAbrams]

Yeah, I don't do that. I write the math expressions in the queries.