> "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

Wed, 03 Nov 1999 10:37:49 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: incomplete info from original message
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


Wed, 3 Nov 1999 21:36:22 -0800
"nicks.emails" <nicks.emails@ic24.net>
your commnts