[postgis-devel] Geom/Geog Hack Plan

[Paragon Corporation]

Nicklas,
Well actually we wouldn't change it in a micro release.  Yes I agree
changing output in the micro release is probably a no no.
 
We'd change it in a minor or major release (proably major in this case in
2.0).  As far as naming goes yes that is the basic argument.  That if we
replace the function with a real one.  The real one will do "more the right
thing" than the old.  So in essense it would be treated like a bug fix
rather than a mere change of behavior.
 
That does bring up the question of:
Is the right answer the one you are expecting or the one you expect.
 
(are expecting meaning the one you are used to vs. you expect (without any
prior expectations of behavior))
 
For example in SQL 1/2 => 0 (both PostgreSQL and SQL Server and a lot of
relational databases behave this way by the way)
 
But if I change the behavior to suddenly return  0.5 (like MySQL does)
 
Do people consider it wrong because it is no longer the expected answer of
0, but from a mathematical point of view, it is the one you expect.
 
Thanks,
Regina

  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
nicklas.aven at jordogskog.no
Sent: Tuesday, November 03, 2009 6:07 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Geom/Geog Hack Plan


Just a question for my understanding. 
What's the argument against a special prefix in function-name for those
functions.
If the argument is that we then can implement the "real" function in a
micro-release, I don't think it is a good argument.
Exchanging the hacked version with the real will cause a changed behavior of
the function and is probably not what users expect from a micro-release,
from the policy not to change functionality in micro-releases.
 
/Nicklas
 



2009-11-03 Paragon Corporation wrote:

Paul and Kevin,
>
>I'm in agreement with Mark too. I suppose one or 2 of these functions is
>not going to pollute our 1.5 that much.
>
>So how about this as a plan:
>
>Paul picks 1 or 2 more of these kind of functions. Note we already have
>buffer -- which is now documented. Though not sure if the documentation is
>clear enough -
>http://www.postgis.org/documentation/manual-svn/ST_Buffer.html (and I think
>we need to revise our documentation template yet again -- though I'll put
>that in a separate note).
>
>The rest of the functions get put in a wiki page and prominently linked
from
>the documentation
>
>
> in geography index
>http://www.postgis.org/documentation/manual-svn/ch08.html#PostGIS_Geography
F
>unctions
>
>as well as geography description page
>
> for easy access
>http://www.postgis.org/documentation/manual-svn/ch04.html#PostGIS_Geography
>
>Is everyone okay with that plan?
>
>Thanks,
>Regina
>
>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091103/00d49371/attachment.html>