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.
> Also, as an application of this function, how about allowing to include
> versions
> in the "requires" list in the control file?
That could be a good feature, but it doesn't follow that an
implementation of it would have any use for this exact function.
It might well be, for example, that the code would need to fetch
the pg_extension catalog entry for other purposes and so could
read the extversion field "for free" then.
BTW, the cfbot claims that this patch doesn't compile. The
error is a little confusing, but I'm suspicious that it somehow
traces to the fact that you applied NameStr to a field that is
not of type "name". See ExecAlterExtensionStmt for known-to-work
code for fetching extversion.
regards, tom lane
