<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [postgis-devel] What's the difference between geom_accum andbuiltin postgresql array_append</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>Getting back to this topic. Recall I said there was a situation where LWGEOM_accum worked where array_append didn't. I can't replicate it so I suspect it was an earlier error in my indexing efforts that caused this issue. I am also not seeing this LWGEOM_accum function used directly in any of the postgis code base.<BR>
<BR>
So here is my half-assed suggestion since no one seems to know why we should maintain the LWGEOM_accum function instead of just using built-in PostgreSQL array_append function.<BR>
<BR>
Simply get rid of LWGEOM_accum from our code base (or deprecate it) -- change<BR>
<BR>
/**CREATE OR REPLACE FUNCTION st_geom_accum(geometry[], geometry)<BR>
RETURNS geometry[] AS<BR>
'$libdir/liblwgeom.dll', 'LWGEOM_accum'<BR>
LANGUAGE 'c' IMMUTABLE;<BR>
***/<BR>
<BR>
To:<BR>
CREATE OR REPLACE FUNCTION st_geom_accum(geometry[], geometry)<BR>
RETURNS geometry[] AS<BR>
$$ SELECT array_append($1,$2); $$<BR>
LANGUAGE 'sql' IMMUTABLE;<BR>
<BR>
<BR>
And that's it. In tests I've done doing above, I don't see a definitive speed difference and all aggs we have seem to have this function for collecting geometries. <BR>
<BR>
I would have suggested replacing our use in aggregates directly with array_append, but thought it would be better to keep this buffer for 3 reasons<BR>
1) We don't have a CREATE OR REPLACE AGGREGATE which makes changing aggs without a drop reload tricky. Changing this function will auto-magically correct the aggs. Granted 1.4 people should be doing a full reload anyway.<BR>
<BR>
2) Don't know if anyone is relying on the st_geom_accum function so we probably should keep it around anyway.<BR>
<BR>
3) In case we are wrong. It won't be a major undertaking to correct the mistake.<BR>
<BR>
Any thoughts, concerns?<BR>
<BR>
Thanks,<BR>
Regina<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Mark Cave-Ayland<BR>
Sent: Wed 8/20/2008 11:16 AM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] What's the difference between geom_accum andbuiltin postgresql array_append<BR>
<BR>
Paul Ramsey wrote:<BR>
>> Yeah, that's one good argument. The reason the 8.3 changes hit us so hard<BR>
>> were because we were accessing the varlena structures directly rather than<BR>
>> using the relevant macros :(<BR>
><BR>
> Speaking of which, I see those damned macros sprinkled hither and yon,<BR>
> but I have no idea where they are documented. PgSQL source code only?<BR>
> It would be nice to know what they do.<BR>
><BR>
> P.<BR>
<BR>
Yeah, it's generally a case of "read the source" :( While it can be<BR>
tricky to find the relevant header file, the macros are generally well<BR>
documented when you do find them.<BR>
<BR>
<BR>
ATB,<BR>
<BR>
Mark.<BR>
<BR>
--<BR>
Mark Cave-Ayland<BR>
Sirius Corporation - The Open Source Experts<BR>
<A HREF="http://www.siriusit.co.uk">http://www.siriusit.co.uk</A><BR>
T: +44 870 608 0063<BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>