Andrew Dunstan wrote: > >For Win32, we could use the registry. For Unix, we can't use /etc > >because we can't be sure we are root. Can we create a dot-file in the > >user's home directory during install? > > > > We can't be sure we are Administrator either.
Exactly. IMHO, using the registry is the worst possible solution, for the reasons Andrew has already pointed out (ie. multiple installs, user privileges, ...). > Binaries can find other binaries the way they do now: look in our own > location, then in the path. > > Other files could be found by looking in 1) as per commandline (e.g. -L > in initdb) 2) hardcoded location, 3) our-location/../share I concur (ie. on 2, the hard-coded configure location, which is c:/msys/1.0/local/pgsql/<etc> on my box, will rarely point to anything useful on a virgin user machine, and could point to the wrong thing on a developers machine with multiple installs... hmmm). I'm yet to see a convincing argument for why we can't adopt the "binary-location/../share" approach as submitted late March. AFAICS, it was rejected on the basis that it was not platform independent (no arguments there) and that we could not rely on the ".." approach. Well, why not? It would greatly simplify the Win32 installer as users need only nominate where they want PostgreSQL to live (ie. all it has to do in this regard is dump the entire pgsql directory structure under a single root, without any config), and windows users who go and muck with the internal directory structure of their installed apps don't generally expect their app to continue working... :-) The other thing to point out is that, given that it is reasonable to expect that the vast majority of Windows users won't be rolling their own install, a solution for this is *needed* for Win32, but is merely a desirable for the other platforms. If this idea is to be rejected on the grounds that we'd like a platform independent solution, then I'd like to see discussion focused in this regard. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html</a> ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
