> > > 5. Geographic data types. PostgreSQL
> > > is way ahead here.
>
> I know I'm butting in, but on this point, I just wanted to inject a word

of caution.

>
> Postgres isn't way ahead because it supports geographic data types -- it's

ahead because they

> realized and emphasized the idea that datatypes, functions, and the

languages you write them in

> should all be pluggable modules. If you want to catch up, this is not a

case for "Firebird adds

> support for geographic datatypes", it's a case for "Firebird rethinks its

typing system, and

> geographic datatypes happen to be some of the first benefits".
>
> I know there's been talk of external functions, java VM's, namespaces,

etc., but how much talk has

> there been about what a type system should look like in a good RDBMS?

About what the term "domain"

> really means? Wouldn't the developer you task with adding geospatial

datatypes find it more

> rewarding to open Firebird up to 3rd party datatype plugin development

than to implement a single,

> complicated datatype in the current code?
>
> Butting back out ...
>
> -Philip

What he said.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com