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