Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0) - Mailing list pgsql-bugs

From Alex Hunsaker
Subject Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)
Date
Msg-id 34d269d41002241817o6f7c0639k7a3d80cc9d3ea5f3@mail.gmail.com
Whole thread Raw
In response to New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)  (Tim Bunce <Tim.Bunce@pobox.com>)
Responses Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)  (Alex Hunsaker <badalex@gmail.com>)
List pgsql-bugs
On Tue, Feb 23, 2010 at 15:23, Tim Bunce <Tim.Bunce@pobox.com> wrote:

> I believe (but haven't yet confirmed) that the problem here is recursion.
> This affects all versions of PostgreSQL.

Hrm... This seems to work for me in HEAD.  It certainly breaks in 8.3.
 Am I missing something?

----
$ bin/psql postgres
psql (9.0devel)
Type "help" for help.

postgres=#  CREATE OR REPLACE FUNCTION foo( integer) RETURNS SETOF INT
LANGUAGE plperl AS $$ $$;
CREATE FUNCTION
postgres=# \q
$ bin/psql postgres
psql (9.0devel)
Type "help" for help.

postgres=#  CREATE OR REPLACE FUNCTION try() RETURNS VOID LANGUAGE plperl AS $$
       my $sth = spi_query("SELECT id FROM foo( 0 ) AS g(id)");
       while( my $row = spi_fetchrow($sth) ) {
       }
   $$;
CREATE FUNCTION
postgres=# SELECT try();
 try
-----

(1 row)

Seems like assuming I did the above correctly we just have a bug in
the older branches where the "SELECT id FROM foo(0)..." part is
getting compiled/executed in the wrong perl context.  In-fact I would
not be surprised at all if there are other dragons lurking when plperl
calls something that tries to compile/call a plperl function.  Safe
>2.20 or older.

Ill keep digging.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: to_timestamp error handling.
Next
From: Alex Hunsaker
Date:
Subject: Re: New PL/Perl failure with Safe 2.2x due to recursion (8.x & 9.0)