4D Geometry - Mailing list pgsql-hackers

Please excuse any stupidity, as although I've used postgres for quite some time, this is my first foray into
developingfor it. I'm working on converting the geometry stuff in adt to support 4 dimensions. For my own use, I plan
onpatching 8.0.3 with the files I edited in the 8.1beta source, right away. I really ownly need the ability to store 4D
(Ido 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/debatethings. Any and all questions/comments/criticisms are welcomed and encouraged. Here are my questions. <br
/><br/> 1.) Is anyone else currently working on this?<br /><br /> 2.) 75% of the changes were trivial and most of the
remaining25% are complications due to the way "line" is implemented.  Particularly, the fact that it uses the 2D
specificAx + 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'tsee any other changes that would be necessary. Can anyone, more familiar with the source, think of any good
reasonsthat 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
littleless confusing. Also A & B should be a vectors, but I'll get to that in a later question.]<br /><br /> 3.) As
itstands now, I added support for the extra dimensions to pair_encode, pair_decode, and pair_count. Do you think that
itwould be better to:<br />     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.<br />     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
thinkingof 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.<br /><br /> 4.) If changing the signatures for these routines presents problems, will the fact that I changed
othersignatures to support the additional coordinates, also present any problems?<br /><br /> 5.) As it stands now, I'm
justusing the Point structure to denote vectors in component form, and LSEG for stpt-endpt form. Does anyone see any
reasonI shouldn't do this. I realize that having a separate VECTOR structure would probably be more readable, and
probablymore useful, but it would more than likely be more work initially.<br /><br /> 6.) Are there any objections to
breakingup geo_ops.c into separate sources?<br /><br /> 7.) Can anyone think of any issues that I'm missing? <br /><br
/><br/><table cellpadding="0" cellspacing="0" width="100%"><tr><td> Chris<br /><br /> --<br /> Sometimes I wonder
whetherthe world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain
</td></tr></table>