On Sun, 2 Feb 2025 00:15:25 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yugo Nagata <nagata@sraoss.co.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@sraoss.co.jp>
