Re: zlib for pg_dump
От | Peter Eisentraut |
---|---|
Тема | Re: zlib for pg_dump |
Дата | |
Msg-id | Pine.LNX.4.21.0007060240080.347-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: zlib for pg_dump (The Hermit Hacker <scrappy@hub.org>) |
Список | pgsql-hackers |
The Hermit Hacker writes: > I don't agree ... unless we're gonna add this for libreadline > (optional) and anything else that is "optional". We already do this for everything else that's optional, except for readline, which I consider wrong, but there's probably no support to be gained for that. The fact that it is virtually impossible to determine whether readline and/or history support is supported in psql until you have installed and used it is a major source of user problems. > IMHO, if the system has the functionality that extends the usefulness > of the software, don't make the installer go off looking for how to > make use of it ... That's why I suggested assuming it by default and turn if *off* manually. The reason why I'm so keen about this is this: configure scripts are not only run by humans, but also by programs, and the only thing programs can rely on is a non-zero exit status. config.status is one such program. Others are source RPMs and other packaging mechanisms. Rebuilding a source RPM is an enlightening experience: You get all kinds of garbage flying by on your screen, and the end you only hope that something reasonable came out. But if not even the build script can determine what it's going to build, then you really lose. The failure modes are plenty. You don't even have to be on a different machine or fiddle with your installed packages. Maybe the sysadmin simply reran /sbin/ldconfig after forgetting for a few months. Before you know it you have shipped the package off to thousands of people who wonder why feature X won't work. The bottom line is, the packager/builder needs a way to specify what exactly is going to be built. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: