Chris Traylor <[EMAIL PROTECTED]> writes: > 1.) Is anyone else currently working on this? No, and AFAIR no one has ever even asked for it. I'm a little dubious about doubling the storage requirements for geometry data and likely creating backwards-compatibility issues to implement a feature that only you need. I'd suggest keeping these as separate private types rather than expecting that a patch to replace the 2D types will be accepted.
What do you think about making it a configure option, i.e. --enable-4D-geometry (default false)? This way people who don't want/need the extra overhead don't have to deal with it, and those who want to use postgres for scientific/engineering/animation/etc apps (where 2D doesn't quite cut the mustard) can have it available to them. I was thinking that it would allow a whole new set of applications to take advantage of the fact that postgres provides native geometric types. After all, you can use just about any db engine to handle geometric data with traditional sql and stored procedures. The point of the builtins is so you have a standard set of algorithms, and that you don't have to constantly reinvent the wheel. Like I said in my earlier message, I can patch the source for myself, and go about my merry way. The geometry portions really don't seem to change very frequently (the differences between 8.0.3, and 8.1beta were minimal), and except for the line stuff, the changes were trivial, so personal maintenance shouldn't be a problem. I just thought I'd share my work.:-)
regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
|
Chris -- Sometimes I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain |
