First I just want to say thanks for posting this code, worked flawlessly for me. I was doing some testing with alternate methods (in Postgres), looking for the fastest execution speed when I found this post.

The thing that surprised me and keeps me from implementing this into our radial proximity search, is that this singular, alternative query:

$sqlselect_in_radius_zip = pg_exec(“SELECT * FROM zips_us_tbl
WHERE (((acos(sin(($latitude*pi()/180)) * sin((lat*pi()/180))+cos(($latitude*pi()/180)) * cos((lat*pi()/180)) * cos((($longitude-lon)*pi()/180))))*180/pi())*60*1.1515) <= $radius
GROUP BY zip,city,state,lat,lon") or die(pg_errormessage());

Executes 3-4 times faster for me and without the use of functions, even when I'm using a huge proximity range and pulling in thousands of results. I was hoping that by using PLPGSQL functions, I could cut query time and let Postgres do more of the "speedy" work but that just wasn't the case.

I like the method of math you are using in your calculations and also the fact that there's an option for passing miles VS kilometers as well. Both methods seem to return very similar results and get the job done but for practical reasons, I have to opt for speed and ditch the functions.

Just thought I'd post that info in case you found it interesting or wanted to test it out. Maybe there's a way to refine the process, pull it into one single function and get it optimized.

Thanks again for putting the work together, very easy to implement.