Re: Extension Packaging - Mailing list pgsql-hackers

On Apr 28, 2011, at 7:04 AM, Tom Lane wrote:

> I think what we're discussing here is bug-fix revisions that don't
> affect the SQL declarations for the extension.  Presumably, that means a
> change in the C code, so the shared library is the right place to keep
> the revision number.  A version number in the control file seems to
> carry a nontrivial risk of being out of sync with the actual code in the
> shared library.

But that's exactly where it is stored right now.

> What's not clear to me is whether to just suggest that extension authors
> who care about this should provide a foo_version() function, or to try
> to standardize it a bit more than that.

Please, if those are the choices, go with the latter. If you leave it to extension authors, they'll all have different
namesand different return types, and will thus be worthless to most folks wanting a generalized way to see what
versionsof extensions they have installed. Hell, I already regret that pgtap_version() returns NUMERIC. Which reminds
me,I might change it in a future version. Then it's *really* inconsistent, isn't it? 

> One point worth thinking about is that not all extensions will have
> a shared library at all --- SQL-only extensions have been mentioned
> several times as an important use case.  For those, there's no such
> thing as an update that doesn't change the script file, and we shouldn't
> try to impose a requirement of providing a lower-level revision number.

No, but there are new releases without code changes. I've been making releases that tweak documentation and the
Makefile(for 9.1 support) but not the code. Should the extension in this case get a new version or not? 

Look, I read this thread this morning carefully, but I have to say I don't really understand it. Considering that there
wasconsensus on not requiring any format, meaning, or mandated sort ordering of versions, there's suddenly quite a lot
ofdiscussion of the meaning and format, if not sort ordering. 

So maybe it's half-assed. Maybe the version can be anything but the revision must be an integer. Maybe there's a
`pg_extension_version($extension_name)`function that returns ARRAY[$version, $revision], and the revision is set in the
controlfile but not included in the version or in the upgrade file names. I think I can live with that. But, hell,
you'rehalfway to mandating the meaning by doing this. Will we have to go the rest of the way in the future? 

Best,

David