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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
