[postgis-devel] Re: getrelid && list_nth

['strk']

I've applied Romi's patches (slightly modified).
And added you postgis_gist75.c (adding infinite geometry handling to it).
Don't like the handling in Makefile... but we can fix that later.

As for the list_nth copy in postgis_estimate.c, I've removed it.
It seems to build and run anyway now.
Yet estimator work is far from correct... enabling debugging output
shows weird results, with nan and inf values coming out often...

--strk;


On Wed, Jun 09, 2004 at 10:56:49AM +0200, 'strk' wrote:
> On Wed, Jun 09, 2004 at 09:39:26AM +0100, Mark Cave-Ayland wrote:
> > Hi strk,
> > 
> > > -----Original Message-----
> > > From: strk [mailto:strk at keybit.net] 
> > > Sent: 08 June 2004 18:19
> > > To: Mark Cave-Ayland
> > > Cc: postgis-devel at postgis.refractions.net
> > > Subject: getrelid && list_nth
> > > 
> > > 
> > > Hello Mark,
> > > I was writing this to pgsql-hackers, but I've solved it
> > > so I turned it into a report.
> > > 
> > > Working on postgis selectivity function for type 'geometry' 
> > > I've incurred in the following problem:
> > > 
> > > The getrelid() macro defined in parser/parsetree.h invokes
> > > the rt_fetch() macro therein defined, which in turn invokes list_nth. 
> > > 
> > > Now list_nth() is not a macro, and postgis
> > > is not linked to postgresql dynamic library, so
> > > it fails to load.
> > > 
> > > This worked until some months ago (PG was already
> > > versioned as 75dev).
> > 
> > FYI the List API has recently changed in PostgreSQL 7.5 which is
> > probably why this has broken - please see the following links:
> > 
> > http://archives.postgresql.org/pgsql-patches/2004-05/msg00344.php
> > http://archives.postgresql.org/pgsql-patches/2004-05/msg00376.php
> > 
> > and the thread here:
> > 
> > http://archives.postgresql.org/pgsql-patches/2004-05/msg00500.php
> > 
> > 
> > > To fix this I've copied list_nth and list_nth_cell into 
> > > postgis_estimate.c removing superflous ( I hope ) checks on 
> > > boundaries.
> > 
> > Yuck. I don't think we should be duplicating the PostgreSQL list API
> > just because the API has changed between versions. Any chance you could
> > look at the posted patch and correct CVS so that this is not needed?
> 
> Do you mean the PGSQL List API change patch ?
> 
> > 
> > > Now estimation selectivity is back up and runnign for PG75
> > > 
> > > Still... any stable utility interface would be appreciated.
> > 
> > BTW did you find that building large GiST indices crashes PostgreSQL?
> 
> Nope. I haven't been playing with PG75 for a while.
> 
> > Since the GiST API has changed you will probably need to apply my "super
> > patch" in order to get things working correctly as the problem wasn't
> > just a Win32 issue (see
> > http://postgis.refractions.net/pipermail/postgis-users/2004-May/004918.h
> > tml)
> > 
> > Would any developers object if the "super patch" for 7.5 were to be
> > applied to CVS? If no-one objects I'd like to apply it real soon....
> 
> I'll take a look at it.
> 
> --strk;
> 
> > 
> > 
> > 
> > Cheers,
> > 
> > Mark.
> > 
> > ---
> > 
> > Mark Cave-Ayland
> > Webbased Ltd.
> > Tamar Science Park
> > Derriford
> > Plymouth
> > PL6 8BX
> > England
> > 
> > Tel: +44 (0)1752 764445
> > Fax: +44 (0)1752 764446
> > 
> > 
> > This email and any attachments are confidential to the intended
> > recipient and may also be privileged. If you are not the intended
> > recipient please delete it from your system and notify the sender. You
> > should not copy it or use it for any purpose nor disclose or distribute
> > its contents to any other person.
> >