On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
> We're using SLES10. If we installed the latest from the SuSE site, we
> would be at PostgreSQL version 8.1. Now, to their credit, that is
> 8.1.17; but we're looking at when to upgrade from 8.3 to 8.4, not at
> whether to go back to 8.1.
Well, that is not surprising. At the time SLES 10 was released,
PostgreSQL 8.1 was the stable PostgreSQL release. If you want major
upgrades, you shouldn't be looking for the SLES 10 upgrade channel to
provide you that. If you want to have out-of-line, unsupported updates,
you can get them from the OpenSuse build service. I think you will find
exactly the same/analogous situation for any enterprise Linux
distribution or other operating system.
> And unless I'm remembering incorrectly, the configure options are not
> what we would want. I don't see any reason the packaged build
> shouldn't be with --enable-debug on a platform where that has no
> performance hit.
Debatable, but it's not upstream default, so why should it be downstream
default?
> I never understood why anyone converting to
> PostgreSQL would want the floating point approximate timestamps rather
> than using --enable-integer-datetimes.
Backward compatibility. Same issue with RHEL; discussion in archives.
> We don't have a need for
> multiple languages, so I figure it's best to use --diable-nls,
> although I doubt that one's a huge deal.
Well, that's not a reason to rebuild from source, although it could be a
reason to rebuild the RPM.
> I wouldn't expect a packaged SuSE build to cater to all of that; but
> it would be nice if they donated their init script to the PostgreSQL
> project, so that those of us who have a reason to build from source
> on SuSE have have a convenient starting point in the source
> distribution of PostgreSQL.
Well, no one needs to donate anything. If you are interested in
maintaining it, just take it and put it under contrib/start-scripts.