>
> ERROR: operator does not exist: integer = integer[]
> HINT: No operator matches the given name and argument type(s).
> You might need to add explicit type casts.
>
Sounds like you are trying to return directly the query.
You must do a loop with that query inside (cursor) and
use ne
Martijn van Oosterhout wrote:
On Wed, Mar 14, 2007 at 08:09:24PM -0400, Kenneth Downs wrote:
What I have noticed is that once the innermost instance exits, none of
the outer instances execute any further, suggesting that the plperl
routine is not "re-entrant" (if I am using that term correct
On Wed, Mar 14, 2007 at 08:09:24PM -0400, Kenneth Downs wrote:
> What I have noticed is that once the innermost instance exits, none of
> the outer instances execute any further, suggesting that the plperl
> routine is not "re-entrant" (if I am using that term correctly).
Doesn't sound right, do
1 -- Drop your indexes on the table to be inserted into.
2 -- Execute a BEGIN transaction
3 -- Execute your inserts.
4 -- Execute a commit or rollback and END transaction
5 -- Rebuild / recreate your indexes
"Alex" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
> i am havin
Alex <[EMAIL PROTECTED]> writes:
> The initial select is pretty fast and first inserts very fast, but after
> a few thousand inserts the inserts start to slow down until it crawls.
> Writing the same in a normal perl script takes less than 90 seconds
> while the function is taking 10 minutes.
Can
On Mon, Sep 19, 2005 at 10:52:23AM +1200, Brent Wood wrote:
> I have a plperl function returning an int. The int is returned as the
> result of a system call.
>
> It is set to return a null if one of the inputs is null, but I can't see
> how to return a null if the result is indeterminate. The fun
On 4/22/2005 2:08 PM, Tom Lane wrote:
Sven Willenberger <[EMAIL PROTECTED]> writes:
We have a replication set up between 2 servers using Slony; both are
runnind PostgreSQL 8.0.1. The issue is that when updates/inserts are
made to a replicated table, the replication does not occur; apparently
this i
On Fri, Apr 22, 2005 at 03:09:13PM -0400, Sven Willenberger wrote:
> On Fri, 2005-04-22 at 14:43 -0400, Alvaro Herrera wrote:
> > On Fri, Apr 22, 2005 at 02:24:57PM -0400, Jan Wieck wrote:
> > > On 4/22/2005 2:08 PM, Tom Lane wrote:
> > >
> > > >Sven Willenberger <[EMAIL PROTECTED]> writes:
> > >
Sven Willenberger <[EMAIL PROTECTED]> writes:
> We have a replication set up between 2 servers using Slony; both are
> runnind PostgreSQL 8.0.1. The issue is that when updates/inserts are
> made to a replicated table, the replication does not occur; apparently
> this is due to spi_exec somehow not
On Fri, 2005-04-22 at 14:43 -0400, Alvaro Herrera wrote:
> On Fri, Apr 22, 2005 at 02:24:57PM -0400, Jan Wieck wrote:
> > On 4/22/2005 2:08 PM, Tom Lane wrote:
> >
> > >Sven Willenberger <[EMAIL PROTECTED]> writes:
> > >>We have a replication set up between 2 servers using Slony; both are
> > >>ru
On Fri, Apr 22, 2005 at 02:24:57PM -0400, Jan Wieck wrote:
> On 4/22/2005 2:08 PM, Tom Lane wrote:
>
> >Sven Willenberger <[EMAIL PROTECTED]> writes:
> >>We have a replication set up between 2 servers using Slony; both are
> >>runnind PostgreSQL 8.0.1. The issue is that when updates/inserts are
>
Subject: Re: [GENERAL] PLPERL function
error - utf-8 to iso8859-1
10/14/2003
"Patrick Hatcher" <[EMAIL PROTECTED]> writes:
> Trying to create a plperl function to strip non-friendly mainframe
> characters from a string. However, when I try to add the Trademark symbol
> (™) as a replace criteria, PG spits back an error:
> ERROR: Could not convert UTF-8 to ISO8859-1
AFAICT
13 matches
Mail list logo
