On Thu, Feb 25, 2010 at 04:06:51PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> >> There seem to be no good answers here.
>
> > There is one fairly good answer:
>
> > Use a perl that's
On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>
> >> That's two unacceptable alternatives, you need to find a third one.
> >> I think most people will have no trouble settling on "do not upda
On Wed, Feb 24, 2010 at 10:58:17PM -0500, Tom Lane wrote:
> Alex Hunsaker writes:
> > On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> >> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
> >>> Seems entirely unacceptable.
>
> >> I think we will see if we can get this fixed on the Safe/perl s
On Tue, Feb 23, 2010 at 02:59:05PM -0700, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 14:29, Tim Bunce wrote:
> > David Wheeler has discovered a new PL/Perl failure when using Safe 2.2x.
>
> *sigh*.
>
> Thanks for all the testing David! And of course many thanks to Ti
[Resend. I misspelled the mailing list address on the original.]
David Wheeler has discovered a new PL/Perl failure when using Safe 2.2x.
It's not good.
In this email I'll try to explain the cause and some possible solutions.
PL/Perl compiles plperl functions inside a 'Safe compartment' which
r
On Tue, Feb 23, 2010 at 04:02:11PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Mon, Feb 22, 2010 at 04:31:05PM -0500, Tom Lane wrote:
> >> I still think that this is optimizing the wrong thing. We care about
> >> the clarity of the message the user sees, n
On Mon, Feb 22, 2010 at 04:31:05PM -0500, Tom Lane wrote:
> Alex Hunsaker writes:
> > How about something like the below?
>
> I still think that this is optimizing the wrong thing. We care about
> the clarity of the message the user sees, not about how short or clean
> the Perl code is. I'm inc
Using
perl -e 'use 5.008010'
would be a more reliable way for configure to test the perl version.
Tim.
On Mon, Feb 22, 2010 at 05:57:56PM +, Jonathan Duke Leto wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5339
> Logged by: Jonathan "Duke" Le
On Fri, Feb 19, 2010 at 02:22:33PM -0700, Alex Hunsaker wrote:
> On Fri, Feb 19, 2010 at 14:00, Tim Bunce wrote:
> > On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
> >> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
> >> > It seems to me
On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
> > It seems to me a more correct fix would be to require utf8; inside of
> > the safe like we do strict.
> >
> > Id favor this approach as if you have utf8 strings the likely
On Fri, Feb 19, 2010 at 09:00:59AM -0800, David E. Wheeler wrote:
> On Feb 19, 2010, at 1:13 AM, Tim Bunce wrote:
>
> >> Hrm. I don't have this bug with Safe 3.19, FWIW.
> >
> > That's because Safe 1.19 (which I presume you meant) doesn't execute
>
't be needed. (Other than it possibly being worthwhile
to detect the 'bad' versions of Safe.)
Tim.
On Fri, Feb 19, 2010 at 09:30:41AM +, Tim Bunce wrote:
> On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> > On Thu, Feb 18, 2010 at 11:09, Tim Bunce
On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> > The key line is:
> >
> > *PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
>
> Hrm... It seems to work for me in HEAD and AFAICS we dont have that
&
On Thu, Feb 18, 2010 at 01:36:59PM -0800, David E. Wheeler wrote:
> On Feb 18, 2010, at 10:09 AM, Tim Bunce wrote:
>
> > It took a depressingly large number of intense hours to work out what
> > was going on and then more to try to work out a relatively clean solution.
>
On Thu, Feb 18, 2010 at 10:50:23AM +, Tim Bunce wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5334
> Logged by: Tim Bunce
> Email address: tim.bu...@pobox.com
> PostgreSQL version: 8.4.2
> Operating system: OS X
>
The following bug has been logged online:
Bug reference: 5335
Logged by: Tim Bunce
Email address: tim.bu...@pobox.com
PostgreSQL version: 8.4.2
Operating system: OS X
Description:GUC value lost on exception
Details:
andrew=# SET SESSION plperl.use_strict = on
The following bug has been logged online:
Bug reference: 5334
Logged by: Tim Bunce
Email address: tim.bu...@pobox.com
PostgreSQL version: 8.4.2
Operating system: OS X
Description:Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL
8.4
Details:
Version 2.22 of
On Thu, Jan 14, 2010 at 08:45:06PM +, Tim Bunce wrote:
> On Thu, Jan 14, 2010 at 06:41:52PM +0000, Tim Bunce wrote:
> > > > David E. Wheeler wrote:
> > > >> Found in 8.4.2, replicated in HEAD. Steps:
> > > >>
> > > >> 1. Create P
On Thu, Jan 14, 2010 at 06:41:52PM +, Tim Bunce wrote:
> > > David E. Wheeler wrote:
> > >> Found in 8.4.2, replicated in HEAD. Steps:
> > >>
> > >> 1. Create PL/Perl function.
> > >> 2. Run it.
> > >> 3. Create same fu
> > David E. Wheeler wrote:
> >> Found in 8.4.2, replicated in HEAD. Steps:
> >>
> >> 1. Create PL/Perl function.
> >> 2. Run it.
> >> 3. Create same function with PL/PerlU
> >> 4. Run it.
> >> 5. Create same function again with PL/Perl
> >> 6. Boom.
>
> > This was just discussed in -HACKERS. Hav
On Tue, Sep 22, 2009 at 10:13:24AM -0400, Tom Lane wrote:
>
> Another point that comes to mind is shared_preload_libraries: if plperl
> is loaded once in the postmaster, it seems entirely likely that the same
> END block would be executed in multiple backends after having been
> loaded only once.
On Mon, Sep 21, 2009 at 07:30:51PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, Sep 21, 2009 at 12:06:30PM -0400, Alvaro Herrera wrote:
> >>> With connection poolers, backends can last quite awhile. Is it OK
> >>> for the END block to run hours after the rest of the code?
Yes.
> >>
On Sun, Sep 20, 2009 at 10:00:01PM -0400, Alvaro Herrera wrote:
> There's a definitional problem here however. When should we call the
> destructor? My impression is that it should happen when the calling
> query terminates, not when the backend shuts down. I'm sure this will
> cause other issue
On Sat, Sep 19, 2009 at 11:43:26PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Sep 19, 2009 at 3:53 PM, Tom Lane wrote:
> >> "Tim Bunce" writes:
> >>> The plperl implementation doesn't call perl_destruct() during server
> >>&
The following bug has been logged online:
Bug reference: 5066
Logged by: Tim Bunce
Email address: tim.bu...@pobox.com
PostgreSQL version: 8.4.1
Operating system: darwin
Description:plperl issues with perl_destruct() and END blocks
Details:
The plperl implementation
25 matches
Mail list logo
