Re: Add a function to get the version of installed extension
От | Yugo NAGATA |
---|---|
Тема | Re: Add a function to get the version of installed extension |
Дата | |
Msg-id | 20250331225506.fbd82b89149cc287f3d36d7b@sraoss.co.jp обсуждение исходный текст |
Список | pgsql-hackers |
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>
В списке pgsql-hackers по дате отправления: