4D Geometry

Please excuse any stupidity, as although I've used postgres for quite
some time, this is my first foray into developing for it. I'm working on
converting the geometry stuff in adt to support 4 dimensions. For my own
use, I plan on patching 8.0.3 with the files I edited in the 8.1beta
source, right away. I really ownly need the ability to store 4D (I do
all the geometry functions outside of the db), so for the public, I'd
really rather do this properly and completely. Since, optimistically,
this won't see the light of day until 8.1.X/8.2, there's plenty of time
to discuss/debate things. Any and all questions/comments/criticisms are
welcomed and encouraged. Here are my questions.

1.) Is anyone else currently working on this?

2.) 75% of the changes were trivial and most of the remaining 25% are
complications due to the way "line" is implemented. Particularly, the
fact that it uses the 2D specific Ax + By + C = 0, and not a vector
style storage. Obviously, I would have to change the line functions in
geo_ops.c, and its spec in pg_type.h, but I've noticed that it only
seems to be used internally, so other than those, I can't see any other
changes that would be necessary. Can anyone, more familiar with the
source, think of any good reasons that would make them leery of me
changing the structure to reflect the parametric form, to say Point *A,
Point *B, double p. [Normally, the parameter would be "t", but I call
the 4th coordinate "t", so I figured "p" would be a little less
confusing. Also A & B should be a vectors, but I'll get to that in a
later question.]

3.) As it stands now, I added support for the extra dimensions to
pair_encode, pair_decode, and pair_count. Do you think that it would be
better to:
a.) leave the original signatures, and use those routines to work
with the old style (x,y) coordinates, and setting (z,t) to (0,0), when
necessary.
b.) create a new set of functions called quad_encode, quad_decode,
and quad_count to work with the new (x,y,z,t) coordinates, and use them
in the code. I'm more thinking of outside stuff, (i.e. libpqxx, etc),
that might use/depend on those signatures. I'm not sure if anything
does, that's why I'm asking. Also, I'm trying to look ahead for when
people that already use the geo types go to upgrade.

4.) If changing the signatures for these routines presents problems,
will the fact that I changed other signatures to support the additional
coordinates, also present any problems?

5.) As it stands now, I'm just using the Point structure to denote
vectors in component form, and LSEG for stpt-endpt form. Does anyone see
any reason I shouldn't do this. I realize that having a separate VECTOR
structure would probably be more readable, and probably more useful, but
it would more than likely be more work initially.

6.) Are there any objections to breaking up geo_ops.c into separate
sources?

7.) Can anyone think of any issues that I'm missing?

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