Re: [HACKERS] perl interface bug?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] perl interface bug?
Дата
Msg-id 9014.908465967@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] perl interface bug?  (Brook Milligan <brook@trillium.NMSU.Edu>)
Ответы Re: [HACKERS] perl interface bug?
Список pgsql-hackers
Brook Milligan <brook@trillium.NMSU.Edu> writes:
> We cannot kill this idea because 'make test' doesn't run without the
> postmaster.  After all, NONE of the regression tests do either!

Edmund is thinking of a different situation.  The perl5 interface is
also a "Perl module", which means that it is supposed to build and
install under very rigid rules --- this is supposed to work:
        perl Makefile.PL
        make
        make test
        make install

If you were installing the perl5 module separately from Postgres proper,
and already had a running Postgres server, that should indeed work.
(With the caveat that you first have to set POSTGRES_HOME environment
variable to /usr/local/pgsql or local equivalent.)

It's not *entirely* clear to me that that's a very plausible scenario,
since we distribute the perl5 module along with Postgres.  But it does
work and we probably shouldn't break it.

Come to think of it, Brook's proposed changes do break the perl5
directory as a standalone Perl module, because it no longer includes a
Makefile.PL, only a Makefile.PL.in.  Can we avoid that by finding some
other way to get the install target directory name into the perl5
makefile?  Maybe, instead of being rewritten by autoconf, Makefile.PL
could actively go look for the directory name, say by looking to see if
../../Makefile.global exists and contains a POSTGRESDIR= line.  If not,
fall back to requiring POSTGRES_HOME to be set.

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: [SQL] Optimizing perfomance using indexes
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: TCL/TK configuration clean-up patches