On Tue, Dec 15, 2009 at 08:35:21AM -0600, Peter wrote:
>After upgrade to 8.4.1 Perl "my" variables are no longer being seen by
> subroutines:
>
> CREATE OR REPLACE FUNCTION global.perl_test()
> RETURNS "varchar" AS
>$BODY$
>my $test="x";
>test();
>return $test;
>s
On Tue, Oct 06, 2009 at 09:18:22AM -0700, David Fetter wrote:
> On Tue, Oct 06, 2009 at 09:34:52AM -0400, Alvaro Herrera wrote:
> > David Fetter wrote:
> > > On Tue, Oct 06, 2009 at 09:57:39AM +0100, Tim Bunce wrote:
> >
> > > > * Enable con
On Mon, Oct 05, 2009 at 11:25:18PM +0100, Tim Bunce wrote:
> I'm planning to work with Andrew Dunstan on some enhancements to PL/Perl
> for PostgreSQL 8.5.
>
> I've written up some initial proposals here:
>
>
> http://blog.timbunce.org/2009/10/05/wishlist-of-plp
I'm planning to work with Andrew Dunstan on some enhancements to PL/Perl
for PostgreSQL 8.5.
I've written up some initial proposals here:
http://blog.timbunce.org/2009/10/05/wishlist-of-plperl-enhancements-for-postgresql-8-5/
I'd welcome any feedback on those, and any other suggestions you ma
On Fri, May 08, 2009 at 04:02:29PM +0200, Daniel Verite wrote:
> Tim Bunce wrote:
>
>> So you're okay with breaking previously working, and prefectly valid,
> DBI code?
>
> I think the rationale is that such code was working by virtue of how
> prepare() was im
On Thu, May 07, 2009 at 06:08:12PM -0700, David Fetter wrote:
> On Fri, May 08, 2009 at 01:02:04AM +0100, Tim Bunce wrote:
> > On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
> > > On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
> > > > On T
On Thu, May 07, 2009 at 06:50:11AM -0700, David Fetter wrote:
> On Thu, May 07, 2009 at 02:31:08PM +0100, Tim Bunce wrote:
> > On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
> > >
> > > WARNING: DBD::Pg now (as of version 1.40) uses true prepared
> > &g
On Thu, May 07, 2009 at 04:54:06AM +1200, Andrej wrote:
> 2009/5/7 JP Fletcher :
> > Hi,
> >
> > I see different behavior with DBI/DBD::Pg (1.607/2.11.8, pg 8.1) when the
> > first command in a prepared statement is 'CREATE TEMP TABLE'.
> >
> > For instance, this works:
> >
> > my $prepare_sql =<
On Sun, Jan 15, 2006 at 02:00:15AM +, Jeremy Nixon wrote:
> Tyler MacDonald <[EMAIL PROTECTED]> wrote:
>
> > [Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
> > prepare_cached failed: FATAL: terminating connection due to administrator
>
> Here's the thing: if your data
On Wed, Nov 30, 2005 at 04:19:18PM -0500, Andrew Sullivan wrote:
> On Tue, Nov 29, 2005 at 07:44:05PM +0000, Tim Bunce wrote:
> > On Tue, Nov 29, 2005 at 10:50:01AM -0800, Tyler MacDonald wrote:
> > > PostgreSQL, doing a SELECT on a table that doesn't exist poisons the r
On Tue, Nov 29, 2005 at 10:50:01AM -0800, Tyler MacDonald wrote:
> Tim Bunce <[EMAIL PROTECTED]> wrote:
> > I'll guess that what you're really after is to be able to call begin_work
> > again whilst an earlier begin_work is in effect and have the DBI keep a
>
11 matches
Mail list logo
