your commnts - Mailing list pgsql-hackers
From | nicks.emails |
---|---|
Subject | your commnts |
Date | |
Msg-id | 000501bf2686$8874eaa0$41646464@toshiba7020 Whole thread Raw |
In response to | Re: incomplete info from original message (Lamar Owen <lamar.owen@wgcr.org>) |
List | pgsql-hackers |
With reference to trying to alter the source code would anyone be able to point me towards the offending code. as another quick(er) fix could someone comment on this Is it possible to create a function written in c/c++ that contains a try statement and within it call the # with the non intersecting lsegs, so when the backend finds that the lsegs don't intersect returns back to the try block and then have a default handler to ignores the error, would the backend return a value before aborting or just abort because I am hoping to be able to spend some time with this function but don't want to waste time unnecesarily. Regards Nick ps sorry to be a nuisance but I am getting desperate. ----- Original Message ----- From: Lamar Owen <lamar.owen@wgcr.org> To: nicks.emails <nicks.emails@ic24.net>; <pgsql-hackers@postgresql.org> Sent: Wednesday, November 03, 1999 7:37 AM Subject: Re: incomplete info from original message > > "nicks.emails" wrote: > > [back on list -- use 'reply ALL' to keep it on list. This is the second > try -- I misspelled pgsql-hackers the first time ;-(] > > > tables to find any intersecting points, I read one of the replies > > about having to recompile the postgres system so as to dereference a > > NULL > > pointer so it is not a null pointer, do you have any info > > to help me to do this. > > I do not have the info to do this. Tom Lane, the one who replied with > that bit, does. However, according to Tom, that whole bit of code is a > mess. > > > Also when will version 7 be available as I was hoping to use postgres > > to complete a > > University project which involves intersecting lsegs and time is > > running out > > I certainly feel for you; however, I have absolutely no control over > that timing -- while I maintain the RPM's for PostgreSQL, the other > developers do most of the core work. I am wanting to help out with that > work, but I don't have sufficient knowledge of the backend yet to do so > (maybe in six months I'll be able to contribute something along those > lines). From what I gather, we're looking at the first quarter of 2000 > for version 7 -- but that is not set in stone, wood, or anything else > solid. > > If you want to do the lseg intersection yourself, you can: > 1.) Retrieve the lseg's and do the intersection in your client program; > 2.) Write a PL/TCL or PL/PGSQL function to do the intersection; > 3.) Write a C function to do the intersection; > 4.) Fix the existing intersection code. > > Number 4 is the most useful, but by far the most difficult of the four > options -- PostgreSQL has a very steep learning curve for developers! > However, the developers here will be glad to help you understand what > needs fixing. > > If and when you do fix this, your patches would be most welcome, of > course. > > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11
pgsql-hackers by date: