Re: Extension Packaging

Hey folks,

I'd kind of like to get this issue nailed down soon so I can update the PGXN HOWTO and illustrate a generally agreed-upon best practice for extension developers. How *do* we want people to use versions in their extension?

Thanks,

David

On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote:

> 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 names and different return types, and will thus be worthless to most folks wanting a generalized way to see what versions of 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 was consensus on not requiring any format, meaning, or mandated sort ordering of versions, there's suddenly quite a lot of discussion 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 control file but not included in the version or in the upgrade file names. I think I can live with that. But, hell, you're halfway to mandating the meaning by doing this. Will we have to go the rest of the way in the future?
>
> Best,
>
> David
>
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers