Robert Haas wrote:
Anyway, I think you've put this pretty well here: the current
definition will make people WANT to use multi-line values for this,
and we don't support that. I think Tim's example is fairly contrived
- setting a global variable here does not seem likely to be useful to
very many users, and the ones who do want it will likely want also
want multi-line values. What IS likely to be useful is preloading a
bunch of perl modules so that backend startup doesn't take an
unreasonably long time. It's nicer to write:
plperl.on_perl_init='strict,warnings,LDAP,HTML::Parser,Archive::Zip'
rather than:
plperl.on_perl_init='use strict;use warnings;use LDAP;use
HTML::Parser;use Archive::Zip;'
I don't know why you would do either of these things. I at least would
load one module which would in turn load others. So I'd expect to see
something like this:
plperl.on_perl_init = 'use lib "/my/app"; use MyApp::Pg;'
I think the suggestion that somehow people will want to put a huge list
of directives straight into postgresql.conf and that this is a reason
not to provide this facility is on the wrong track completely.
I would strongly suggest to Tim that he rip the portions of this patch
that are related to this feature out and submit them separately so
that we can commit the uncontroversial portions first.
See my previous email. I suggested that Tim send three patches: one for
this controversial stuff, one for the new utility functions for plperl,
and one for the remainder. He and I have discussed it and I believe he
is agreeable to that.
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
