On Jun 28, 2006, at 10:14 AM, [EMAIL PROTECTED] wrote:
All the geometric types that I'll never use in core,
with few or no uses, including functions to operate on these types,
and no UUID type... Hehe... To me, that's irony... :-)
Interestingly, the superior geometry capability is driving a lot of
recent migration from MySQL to PostgreSQL in my own experience,
especially with PostGIS. The geometry parts may not get as much love
as other parts, but they still get to leverage the very solid
foundation they are built on top of. The geometry capability of
MySQL is basically checklist in nature, as it lacks the more
sophisticated indexing and query execution that is really required to
get passable performance from queries with geometry in them. MySQL
has similar geometry capability to PostgreSQL in theory if you don't
look too closely, but in practice the engine is not up to the more
rigorous demands of that kind of work.
With the nascent rise of the geospatial web, it is going to become a
lot more important than it has been.
J. Andrew Rogers
[EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
