Aidan Van Dyk wrote:
* Andrew Dunstan <and...@dunslane.net> [100130 19:55]:
If I am developing, say, a new
perl facility, I expect to develop and test using a private installation
of perl, and not screw up my system's perl. It's the same with postgres.
But, perl was a bad example. If you're just trying to develop a new
"perl module", something that other perl scripts can use, to require you
to provide a completely private copy of complete perl, instead of the
perfectly identical (other than paths) version the system provides is a
bit much...
I'm not arguing that the PGXS gripes Ivan has are valid, but your perl
example probably *supports* his case more than you think...
My example was not of a perl module, but of some extra facility inside
the perl engine. But I take your point. OTOH, perl is not a running
server, unlike Postgres.
In any case, the points others have made about needing to develop
against a build with cassert, debug and depends turned on are valid.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
