Query supautils version

[steve-chavez]

Problem

Currently users have no way of knowing the installed supautils version.

Solution

Add a GUC so users can do:

show supautils.version;

---

@soedirgo WDYT?

[soedirgo]

What’s the use case? We don’t want people to start doing weird logic that depends on the config, and if they need to know what the version is, that points to a deeper issue

[steve-chavez]

I wanted to notify the users of #88 about the new version, so they can query it and confirm.

But you're right that it's not a good idea. Just wanted to see there was a need.

Closing.

[soedirgo]

One way is to check the Postgres version (Settings > Infrastructure), since the version of supautils is tied to an AMI version. A side benefit to that is the upgrade button is also on the same page

[steve-chavez]

Reopening since we get questions about event triggers being enabled. Looking at the postgres AMI version adds indirection and time lost, both for the user and developers (I have to hunt which PR added the latest supautils, then check the version in supabase/postgres). Doing a show supautils.version is much easier.

What’s the use case? We don’t want people to start doing weird logic that depends on the config

How's this different than querying the pg_net version or the pg_cron version? I don't see any potential harm for users. Or much weird logic for that matter.

[soedirgo]

I have to hunt which PR added the latest supautils, then check the version in supabase/postgres

That doesn't sound like a lot of friction relative to the need to check which supautils version added the feature.

How's this different than querying the pg_net version or the pg_cron version?

pg_net and pg_cron are extensions with API exposed to users, supautils is not.

Anyway I'm not very particular about this, the potential for harm is very low. As long as we don't use it as replacement for Postgres version in our official docs, since at the end of the day it's an implementation detail that's meant to work transparently to users (i.e. we don't want to have to explain what supautils even is before we provide them with solutions/answers).

[steve-chavez]

This will be natively supported on pg18 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9324c8c58

IMO there was a lot of unnecessary back and forth here. I've been trying to make supautils useful in a general way and not tied to Supabase cloud platform, but that design decision doesn't seem to be clear (or agreed) at all. Hence why there are arguments here concerning AMIs/UIs when those should be off-topic.

pg_net and pg_cron are extensions with API exposed to users, supautils is not.

@soedirgo I'm pretty aware of that since I authored the extension and wrote the README.md stating it is a loadable library. Please try to make meaningful counter arguments, otherwise the back and forth is prolonged unnecessarily.