> On 12/5/11 5:25 PM, David E. Wheeler wrote:
>>> Thus, we probably now have version numbers in pgxn that are no more
>>> >  valid semver. Not only that, but the semver postgres implementation is
>>> >  now less optimal, as the patchname field should be parsed in order to
>>> >  sort. I don't know if it's worth optimize it as it would take some C
>>> >  union juggling to maintain binary compatibility…
>> Yeah, looks like it will have to be split on the dots. What do you think,
> > Sam? I need to read the spec changes in more detail to figure out
> > what needs to change. Do you think it’s do-able?

> Yes, I think it can be done.  The "patchname" field in the struct needs to just start with a "-" or a "+", and the relevant compare function (probably just "patchnamecmp") needs to know how to implement the new logic.  Also the parse code needs to know as well.  It probably won't slow it down measurably - the main performance increase is in moving from a compound type to a struct, probably not so much in the fact that each of the numbers have their own dedicated int32 and don't need parsing.

> So, it seems that there are three allowable suffix forms:

> "1.2.3foobar", which is compared using "strcasecmp" and sorts, well whichever way it sorts - I forget - against "1.2.3"
> "1.2.3-foobar.3", which gets the new sorting rules and sorts older than "1.2.3"
> "1.2.3+foobar.3", which gets the same sorting rules and sorts newer than "1.2.3"

> The first one could be allowed, for compatibility, in the spec and given an explicit sort order relative to the other two forms - probably deprecated.

> It's also possible to get the type to be parameterized, so that you can specify which forms are allowed in a particular column.  I remember that you get something like 1 machine word to store such column options, and this customization will need between 1 and 3 bits so that should be fine.

> Hope that helps!  I'm happy to review/critique/etc changes, not really a consumer of this code at the moment though :)

> Cheers,
> Sam