Re: [HACKERS] perl interface bug?
От | Brook Milligan |
---|---|
Тема | Re: [HACKERS] perl interface bug? |
Дата | |
Msg-id | 199810192258.QAA09626@trillium.nmsu.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] perl interface bug? (Edmund Mergl <E.Mergl@bawue.de>) |
Список | pgsql-hackers |
I envision 2 general classes of postgresql installers: 1) root, and 2) nonroot users wishing to try/use postgresql. In the case of root sysadmins, everything (including perl) should install out of the box. It does so now without affecting the standalone perl interface installation. In the case of nonroot installers, there are two subcases: 2a) perl is installed in system directories with only root access, and 2b) perl was installed in some other place by the postgresql installer. In case 2b, again there is no problem. The install (with a suitable --prefix=... argument to configure) should proceed unimpeded. In case 2a, postgresql is installable under control of the --prefix=... argument, but there will be a conflict when perl is installed do to lack of access to the perl filesystem for the perl interface shared library. In this case, the installer can install postgresql WITHOUT the --with-perl option to configure. Later, someone with root permission can do the cd interfaces/perl5perl Makefile.PLmakemake testmake install sequence. I don't see any situations that lose here. Am I missing something? In conclusion, I see our current perl interface handling as addressing all the relevant conditions (thanks to Tom Lane for finishing it up!). Cheers, Brook
В списке pgsql-hackers по дате отправления: