Re: Add a function to get the version of installed extension

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add a function to get the version of installed extension
Date: 2025-03-31 13:55:06
Message-ID: 20250331225506.fbd82b89149cc287f3d36d7b@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 2 Feb 2025 00:15:25 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> writes:
> > This might be avoidable if the binary is made carefully to check the existing
> > of objects, but I think it is useful if an extension module function can check
> > the current extension version. So, I would like to propose a new function to
> > return the current extension version, get_extension_version. I've attached a
> > patch.
>
> While I don't say this is a bad idea, I do say you've not made a very
> good case for it. How would an extension know its own OID in order
> to call the function? If it did manage to call the function, what
> exactly would it do with the result, and how would that be easier than
> maintaining backwards compatibility with its old SQL definitions?
> We've not found the backwards-compatibility requirement to be hugely
> onerous in our contrib extensions.
>
> A concrete example use-case would make this a lot more convincing.

An OID of an extension can be get from the name using get_extension_oid()
because the name is unique in a database. But, after second thought, this
might not be so useful because the version of an extension is just a text
and would not comparable as a number, so it is hard to say "if the version
is 10.0 or later" and so on.

I'll withdraw this proposal for now until I get a good example use-case.

Regards,
Yugo Nagata

--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2025-03-31 13:57:56 Re: Non-text mode for pg_dumpall
Previous Message Tom Lane 2025-03-31 13:52:44 Re: Thread-safe nl_langinfo() and localeconv()