fix: restore earthdistance function search paths

[nebhale]

Summary

Reapply the public search path for the ll_to_earth and earth_box functions after the earthdistance extension upgrade.

Why

TeslaMate previously added search_path = public for these functions in the PostgreSQL 17 compatibility work because earthdistance functions without an explicit search path can fail to resolve the earth type correctly.

Later, the earthdistance v1.2 upgrade migration updated the extension but did not restore that custom function metadata. That appears to drop the expected search path from the extension-managed functions.

This follow-up migration restores the public search path for both functions.

Context

• Original qualification/search-path issue: ERROR: type "earth" does not exist at character 136 #192
• Search-path hardening added in: PostgreSQL 17 #4231
• Extension upgrade that likely reset the function metadata: feat: check Postgres version on startup, require 16.7 / 17.3, update earthdistance extension #4648

Validation

• mix format priv/repo/migrations/20260312120000_set_search_path_for_earthdistance_functions.exs
• mix compile

[netlify]

✅ Deploy Preview for teslamate ready!

Name	Link
🔨 Latest commit	2647ff3
🔍 Latest deploy log	https://app.netlify.com/projects/teslamate/deploys/69b37a95d489c3000877cbb1
😎 Deploy Preview	https://deploy-preview-5205--teslamate.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[CLAassistant]

All committers have signed the CLA.

[swiffer]

this isn't needed anymore, is it ?

[nebhale]

@swiffer I back my teslamate instance with a Google Cloud SQL PG instance. I've been looking to upgrade form 17 to 18 and it fails some pre-upgrade checks (I have two schemas on the same database):

My guess is that you're right, PG itself doesn't require this but at least Google's managed instances do.

[swiffer]

Ok, seems to be problematic if using inplace upgrade / pg_restore without previously creating the extensions agian like we do in the docs.

# Stop the teslamate container to avoid write conflicts
docker compose stop teslamate

# Drop existing data and reinitialize (Don't forget to replace first teslamate if using different TM_DB_USER)
docker compose exec -T database psql -U teslamate teslamate << .
DROP SCHEMA public CASCADE;
DROP SCHEMA private CASCADE;
CREATE SCHEMA public;
CREATE EXTENSION cube WITH SCHEMA public;
CREATE EXTENSION earthdistance WITH SCHEMA public;
.

# Restore
docker compose exec -T database psql -U teslamate -d teslamate < teslamate.bck

# Restart the teslamate container
docker compose start teslamate

You have been able to upgrade correctly after setting the search_path?

[nebhale]

Yes, I was able to run those two commands manually and upgrade the database. Restarting Teslamate against the modified and upgraded database does not appear to have any problems.

[swiffer]

Good to hear - if we set this via migration - are we able to drop creating the schema and extensions in our own restore?

[nebhale]

My hypothesis is yes, but I've never upgraded this way, so I defer to others on an authoritative answer.

[swiffer]

I will give it a try over the weekend ;)

[brianmay]

Disclaimer: I don't really understand these functions, or why they are required. Or why setting the search path is important. So I might have got details wrong.

I can say that the migration will only run if it has not run before. So if you restore an old backup that hasn't had this migration, it will run the migration. But if you restore a recent backup that already has had this migration applied, it will not run this migration again. Because it is already recorded in the schema_migrations table.

Normally this wouldn't matter, because the backup would also have all the values from all the applied migrations.

If I look at my backup, after manually applying the changes in this migration, the backup does not contain the new search_path values, all I see in my backup is this line:

SELECT pg_catalog.set_config('search_path', '', false);

Which I think might be insufficient. ?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It could be closed if no further activity occurs. Thank you for your contributions.

[nebhale]

I'd like to keep this alive and eventually get it merged if possible. The change does appear to be necessary for some installations and the change has been validated.

[brianmay]

As above, it makes me nervous that this value does not appear to be saved in backups. Do we need to update the restore documentation to include a step to manually fix this?

[nebhale]

Do we need to update the restore documentation to include a step to manually fix this?

Copy that. I'll update the PR.

[netlify]

✅ Deploy Preview for teslamate ready!

Name	Link
🔨 Latest commit	2de5913
🔍 Latest deploy log	https://app.netlify.com/projects/teslamate/deploys/69f618ae0c4c300008db1b3d
😎 Deploy Preview	https://deploy-preview-5205--teslamate.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[nebhale]

Documentation updated and ready for re-review.

[JakobLichterfeld]

Do we need to update the restore documentation to include a step to manually fix this?

No, the issue is only present when someone does not follow the restore docu:

Ok, seems to be problematic if using inplace upgrade / pg_restore without previously creating the extensions agian like we do in the docs.

So imo this PR is not needed

If I look at my backup, after manually applying the changes in this migration, the backup does not contain the new search_path values, all I see in my backup is this line:

SELECT pg_catalog.set_config('search_path', '', false);

Which I think might be insufficient. ?

And as you observed does not provide any meaningful value.

[brianmay]

I do think we need more data to justify the need for this. i.e. what steps are required to reproduce the search_path being unset.

For the record, AI is telling me the solution is not to rely on the search path at all, and prefix everything with "public.", e.g. public.earth_box(public.ll_to_earth(...)).