Tom Allison wrote: > This should be a dumb question: > > --with-perl > > I don't see that I have to do this in order to load pl/perl as a > function/trigger language option. So I should assume that this will > compile pl/perl in rather than having it available as a loadable > function. Nice for optimizations?
If you compile --without-perl you will not be able to use PL/Perl. There will be no loadable module in that case. It is not a question of optimization. > I'm assuming this is the case because there is no option for something > like PL/Ruby support, but Ruby is available as a loadable function. Only if you download, compile and install PL/Ruby, which is a separate module that is not in the PostgreSQL core distribution. That will give you a loadable module for PL/Ruby. Compiling and installing PL/Ruby is the equivalent of building --with-perl (PL/Perl is included in PostgreSQL core). > And should I also be able to assume that PL/PgSQL is compiled into > postgresql? PL/pgSQL is always built, there is no special flag to enable it. > so I don't really need to use any particular flags, with the probable > exception of --with-ssl? Depends. If you want only PL/pgSQL, you need no extra flags. If you need PL/Perl, compile --with-perl. If you want PL/Ruby, you must download, compile and install it. Creating a procedural language in PostgreSQL involves two steps: 1) Build and install the loadable module (which is what my answers are about). 2) Run a CREATE LANGUAGE statement in the database where you want the procedural language. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
