Re: [HACKERS] plperl/plperlu interaction
Mark Dilger wrote: > Tom Lane wrote: >> Andrew Dunstan <[EMAIL PROTECTED]> writes: >>> Anyway, it is probably not expected by many users that loading a module >>> in plperlu makes it available to plperl - I was slightly surprised myself to see it work and I am probably more aware than most of perl and >>> plperl subtleties. >> I think that is a bug and needs to be fixed. We have the precedent of pltcl, which uses separate interpreters for pltcl and pltclu for exactly >> this reason. > > If this is fixed, what becomes the mechanism for an administrator to make > a perl > module available to plperl functions? I didn't see any other way to do this > documented. Thanks, > This isn't documented either :-) I discovered this when I was working on a way of doing this nicely and safely. I hope to have that for 8.3. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] plperl/plperlu interaction
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Anyway, it is probably not expected by many users that loading a module in plperlu makes it available to plperl - I was slightly surprised myself to see it work and I am probably more aware than most of perl and plperl subtleties. I think that is a bug and needs to be fixed. We have the precedent of pltcl, which uses separate interpreters for pltcl and pltclu for exactly this reason. If this is fixed, what becomes the mechanism for an administrator to make a perl module available to plperl functions? I didn't see any other way to do this documented. Thanks, mark ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] plperl/plperlu interaction
Jeremy Drake wrote: On Thu, 26 Oct 2006, Alvaro Herrera wrote: Jeff Trout wrote: On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote: On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote: Perhaps people who use other platforms could look for these flags in the output of perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_sh();' OSX 10.4.8: usemultiplicity='define' usethreads='define' useithreads='define' Same here on Debian unstable (stock Perl packages). On my current Gentoo box: useithreads='undef' usemultiplicity='undef' usethreads='undef' My USE flags have ithreads disabled, since the description of the feature is "Enable Perl threads, has some compatibility problems" On my Ubuntu 'Dapper' system: useithreads='define' usemultiplicity='define' usethreads='define' And I'm getting 'undef' for each of these flags on both Gentoo 2006.1 and Gentoo 1.4 systems using the default perl installation. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plperl/plperlu interaction
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> 3. Support separate interpreters if possible, refuse to run both plperl >> and plperlu functions in the same backend if not. > How would we decide which wins in the third case? "first in" seems > rather arbitrary. If we went that way I'd probably plump for just > plperlu to be allowed. "First used in a given backend" was exactly what I had in mind. Certainly it wouldn't be perfect, but your proposal seems to be "disable plperl altogether if no separate-interpreter support", which seems overly harsh. Especially for someone who doesn't even want to install plperlu. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plperl/plperlu interaction
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: You can also examine the output from perl -V I think we've already established that we won't be able to ignore the case of not having support for multiple perl interpreters :-( So it seems we have these choices: 1. Do nothing (document it as a feature not a bug) 2. Support separate interpreters if possible, do nothing if not (still needs documentation) 3. Support separate interpreters if possible, refuse to run both plperl and plperlu functions in the same backend if not. Any other compromises possible? How would we decide which wins in the third case? "first in" seems rather arbitrary. If we went that way I'd probably plump for just plperlu to be allowed. The the worst effect would be that the functions would have to be created by the superuser. It would be a great pity, of course - this threatens to do horrible things to portability ;-( I guess another possibility would be to allow 3 to be overridden by a switch to become 2. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] plperl/plperlu interaction
Andrew Dunstan <[EMAIL PROTECTED]> writes: > You can also examine the output from perl -V I think we've already established that we won't be able to ignore the case of not having support for multiple perl interpreters :-( So it seems we have these choices: 1. Do nothing (document it as a feature not a bug) 2. Support separate interpreters if possible, do nothing if not (still needs documentation) 3. Support separate interpreters if possible, refuse to run both plperl and plperlu functions in the same backend if not. Any other compromises possible? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plperl/plperlu interaction
Andrej Ricnik-Bay wrote: On 10/27/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: Undef in Slackware 10.2 Def in Ubuntu 6.06 Undef in Mandriva 2006 Undef in Solaris 10 06 Def in SLES 9.2 Perl 5.8 in SLES 8.1 throws a fit: "Array found where operator expected at /usr/lib/perl5/5.8.0/warnings.pm line 294, at end of line (Missing operator before ?) Undefined subroutine &main::config_sh called at -e line 2." Perl 5.004 in solaris 6&7 does't doesn't do config_re, neither does the perl 5.6 in Solaris 9 You can also examine the output from perl -V cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] plperl/plperlu interaction
On 10/27/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: Undef in Slackware 10.2 Def in Ubuntu 6.06 Undef in Mandriva 2006 Undef in Solaris 10 06 Def in SLES 9.2 Perl 5.8 in SLES 8.1 throws a fit: "Array found where operator expected at /usr/lib/perl5/5.8.0/warnings.pm line 294, at end of line (Missing operator before ?) Undefined subroutine &main::config_sh called at -e line 2." Perl 5.004 in solaris 6&7 does't doesn't do config_re, neither does the perl 5.6 in Solaris 9 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] plperl/plperlu interaction
Andrew, > My Debian Sarge (i386) has: > > useithreads='define' > usethreads='define' > usemultiplicity='define' I get the same on Ubuntu and SuSE 9.3, so I think those are pervasive settings for Linux. Solaris 10update1: useithreads='undef' usethreads='undef' usemultiplicity='undef' -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] plperl/plperlu interaction
Andrew Dunstan wrote: > Tom Lane wrote: >> Andrew Dunstan <[EMAIL PROTECTED]> writes: >> >>>Now suppose we have more than one interpreter instance running >>> at the >>>same time. This is feasible, but only if you used the >>> Configure option >>>"-Dusemultiplicity" or the options "-Dusethreads >>> -Duseithreads" when >>>building perl. >>> >> >> >>> Now my local perl (FC5/ia64) has usemultiplicity defined. I am not >>> sure how common this is. >>> >> >> Ouch. It's certainly not the default configuration :-( >> >> >> > > Well, so far many Linux platforms look OK, but FBSD does not. OpenBSD (which has perl in base) also has those 3 NOT defined ... > > This could be ugly ;-( yeah ... Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plperl/plperlu interaction
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Now suppose we have more than one interpreter instance running at the same time. This is feasible, but only if you used the Configure option "-Dusemultiplicity" or the options "-Dusethreads -Duseithreads" when building perl. Now my local perl (FC5/ia64) has usemultiplicity defined. I am not sure how common this is. Ouch. It's certainly not the default configuration :-( Well, so far many Linux platforms look OK, but FBSD does not. This could be ugly ;-( cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plperl/plperlu interaction
On Thu, 26 Oct 2006, Alvaro Herrera wrote: > Jeff Trout wrote: > > > > On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote: > > > > >On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote: > > >>Perhaps people who use other platforms could look for these flags > > >>in the > > >>output of > > >> perl -e 'use Config qw(myconfig config_sh config_vars config_re); > > >>print config_sh();' > > > > > > > OSX 10.4.8: > > > > usemultiplicity='define' > > usethreads='define' > > useithreads='define' > > Same here on Debian unstable (stock Perl packages). On my current Gentoo box: useithreads='undef' usemultiplicity='undef' usethreads='undef' My USE flags have ithreads disabled, since the description of the feature is "Enable Perl threads, has some compatibility problems" -- Whether you can hear it or not The Universe is laughing behind your back -- National Lampoon, "Deteriorata" ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plperl/plperlu interaction
On Thu, Oct 26, 2006 at 03:35:11PM -0400, Jeff Trout wrote: > > On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote: > > >On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote: > >>Perhaps people who use other platforms could look for these flags > >>in the > >>output of > >> perl -e 'use Config qw(myconfig config_sh config_vars config_re); > >>print config_sh();' > > > > OSX 10.4.8: > > usemultiplicity='define' > usethreads='define' > useithreads='define' All 3 are undef on FreeBSD 6.1. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plperl/plperlu interaction
Jeff Trout wrote: > > On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote: > > >On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote: > >>Perhaps people who use other platforms could look for these flags > >>in the > >>output of > >> perl -e 'use Config qw(myconfig config_sh config_vars config_re); > >>print config_sh();' > > > > OSX 10.4.8: > > usemultiplicity='define' > usethreads='define' > useithreads='define' Same here on Debian unstable (stock Perl packages). -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] plperl/plperlu interaction
On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote: On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote: Perhaps people who use other platforms could look for these flags in the output of perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_sh();' OSX 10.4.8: usemultiplicity='define' usethreads='define' useithreads='define' -- Jeff Trout <[EMAIL PROTECTED]> http://www.dellsmartexitin.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] plperl/plperlu interaction
Andrew Dunstan <[EMAIL PROTECTED]> writes: >Now suppose we have more than one interpreter instance running at the >same time. This is feasible, but only if you used the Configure > option >"-Dusemultiplicity" or the options "-Dusethreads -Duseithreads" when >building perl. > Now my local perl (FC5/ia64) has usemultiplicity defined. I am not sure > how common this is. Ouch. It's certainly not the default configuration :-( regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] plperl/plperlu interaction
On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote: > Perhaps people who use other platforms could look for these flags in the > output of >perl -e 'use Config qw(myconfig config_sh config_vars config_re); > print config_sh();' My Debian Sarge (i386) has: useithreads='define' usethreads='define' usemultiplicity='define' Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] plperl/plperlu interaction
Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Anyway, it is probably not expected by many users that loading a module in plperlu makes it available to plperl - I was slightly surprised myself to see it work and I am probably more aware than most of perl and plperl subtleties. I think that is a bug and needs to be fixed. We have the precedent of pltcl, which uses separate interpreters for pltcl and pltclu for exactly this reason. Fair enough. I am not sure what our release timetable is - and presumably this should also be backpatched if we regard it as a bug. I won't be able to do much on this front for the next 2 weeks at least. There is one other wrinkle, that has just come to my attention courtesy of [EMAIL PROTECTED] This is what the perlembed man page says: Now suppose we have more than one interpreter instance running at the same time. This is feasible, but only if you used the Configure option "-Dusemultiplicity" or the options "-Dusethreads -Duseithreads" when building perl. Now my local perl (FC5/ia64) has usemultiplicity defined. I am not sure how common this is. Perhaps people who use other platforms could look for these flags in the output of perl -e 'use Config qw(myconfig config_sh config_vars config_re); print config_sh();' cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] plperl/plperlu interaction
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Anyway, it is probably not expected by many users that loading a module in plperlu makes it available to plperl - I was slightly surprised myself to see it work and I am probably more aware than most of perl and plperl subtleties. I think that is a bug and needs to be fixed. We have the precedent of pltcl, which uses separate interpreters for pltcl and pltclu for exactly this reason. Fair enough. I am not sure what our release timetable is - and presumably this should also be backpatched if we regard it as a bug. I won't be able to do much on this front for the next 2 weeks at least. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] plperl/plperlu interaction
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Anyway, it is probably not expected by many users that loading a module > in plperlu makes it available to plperl - I was slightly surprised > myself to see it work and I am probably more aware than most of perl and > plperl subtleties. I think that is a bug and needs to be fixed. We have the precedent of pltcl, which uses separate interpreters for pltcl and pltclu for exactly this reason. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq