A good starting point would be the closest method in Geo::Distance.

In Perl, you can use Math::Trig::great_circle_distance(). To run queries on the database, you'll need to cook up an SQL function which does the same calculation.

Added: Yes, this would be a good place for a stored procedure.

If he is using Postgresql, could he create a procedure that does this?

If he is using Postgresql then PostGIS might also be helpful.

We've encountered this requirement for http://openguides.org. Here, alongside the lat + long, we store planar X-Y coordinates in the database, using a projection such as UTM or Ordnance Survey. Then, we use Pythagoras in SQL queries to find all entries within the distance.

This works well for city guides - our main application, but less well over large distances, where curvature of the oblate spheroid that is the Earth, becomes a factor.

I don't know what your application is, but check out OpenGuides, as there's probably quite a bit of code you can reuse. Or even set up a Guide yourself, if that's what you are trying to achieve.

I've given some thought to how I'd do this before, and come up with the following:

Pretend the earth is flat. Divide it up into equilateral triangles, each with an id and lat/long of the center. Add the triangle id to your records; if any triangle ends up with an unwieldy number of distinct lat/longs, divide that triangle into 4 sub-triangles like so:

____________
\    /\    /
 \  /  \  /
  \/____\/
   \    /
    \  /
     \/
[download]

I have the feeling database vendors do something like this if they support indexing lat/longs.

Update: why triangles instead of squares? I have a gut feeling that it will produce fewer outside-the-distance results, but am unable to say why.

Nice gut! You're thinking about Dymaxion maps. And CPAN is your friend, in this case.

One other idea. I did this before in MySQL and using the full formulas in SQL was too much, and computing them all in perl was annoying, so instead I computed a square of the right size, found all the matches in that with SQL then refined that down once in my perl script. I hope that doesn't sound like raving lunacy! ;) Shortened: Do a quicker less accurate search in your database, then refine the listing in perl. That is unless of course your database has native support then it is probably going to win speed contests by doing it purely in your database.