2008/7/15 Aaron Joyner <[EMAIL PROTECTED]>: > On Tue, Jul 15, 2008 at 9:05 AM, Dan Scott <[EMAIL PROTECTED]> wrote: <snip> >> Sadly, we may have a bit of a collision in one small area, as I >> committed an initial PostgreSQL 8.3 full text search schema to trunk >> about 8 hours ago - so if a user doesn't specify a PostgreSQL version >> for your script, they'll get 8.3 (and probably suffer ignominous >> failure). > > Yeah, I saw the patch go in and thought briefly about it. In general, > the detection code currently isn't intended to come into play unless > there *isn't* a version in place. So, it won't adversely affect 8.2 > users at present, assuming they properly specify a database version,
Right - and that's the current assumption, so it was indeed an edge case. > but if there are no major changes in version 8.4, you won't need to > check in a file in the same way that 8.1 and 8.2 had their own > duplicated version of the file. On the other hand... that's not too > future proof, it's really just intended to help as a "best guess to > use the last version if one doesn't exist." Note that it's also > currently coupled with really big warnings. :) Saw those - I like your style :) >> The approach I had been thinking about was using the database >> credentials to do an initial login to the database to grab the server >> version (SHOW server_version or SHOW server_version_num, whichever is >> easier to parse) and use that to take the decision out of the user's >> hands. Or at least provide a sanity check. >> >> Would you be interested in taking a crack at refining your patch in >> this fashion? > > I'll be glad to implement this additional sanity check. Do you think > it's worth it to remove the database specification from the user, > detect the database version, and warn on a missing file? I haven't > looked widely enough to see if the database version is used for > anything else in that build chain, my instinct is that can probably be > torn out, and just auto-detected. If that sounds good, I'll cook up a > patch to do that, instead. That sounds great to me. > The more I think abou it, the fewer things the user has to enter > (particularly in the current tediously long build/install process), > the better. I can't think of any reason why the user would want to > specify a different database version at install time, unless he/she > knows the contents of those scripts, in which case he/she's fully > capable of working around the auto detection. :) I'm in full agreement with you. There are plenty of other "learning opportunities" in the install process; the simpler and more robust we can make this, the better. Thanks again! -- Dan Scott Laurentian University
