Re: pg_upgrade's bindir options could be optional
От | Tom Lane |
---|---|
Тема | Re: pg_upgrade's bindir options could be optional |
Дата | |
Msg-id | 17491.1304829644@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade's bindir options could be optional (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > On lör, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote: >> Another >> interesting approach would be to assume the /bin directory is ../bin >> from the data directory. That would work for some installs, >> particularly for people moving things around, but again, it is worth >> trying to default something that isn't going to be 100% right? > In practice, there are the two main camps of parallel installation and > move old installation out of the way. They are probably both pretty big > (Debias camp 1, Red Hat is camp 2, for a start). So it would be worth > doing something to help one camp or the other. It's probably fair to ask whether setting up defaults for this would actually help either "camp". In the case of the Red Hat RPMs, pg_upgrade is invoked via a script which is perfectly content to specify both bindirs explicitly. I doubt I'd remove those options even if I thought the defaults would be right, because there's just no upside to doing so. I would imagine the same is true for Debian --- surely this is pretty mechanized? So the only cases where providing a default is even theoretically useful are those where someone is invoking pg_upgrade manually. I suggest that if that's going on, the situation is probably nonstandard enough that we should have considerable doubt about whether a default is likely to be correct. Again, I don't have any particular fear about defaulting --new-bindir. I *do* have a lot of concern about defaulting --old-bindir. regards, tom lane
В списке pgsql-hackers по дате отправления: