to see the result of the preceding
insert.
By the way: the EXECUTE around the SELECT in the a_bar() function is probably
not required to trigger the bug, but this is the version we tested.
Regards,
Matthijs Bomhoff
BEGIN;
CREATE TABLE foo(i INTEGER);
CREATE TABLE bar(i INTEGER);
CREATE
On May 13, 2011, at 12:46 AM, Tom Lane wrote:
> Noah Misch writes:
>>> Some initial debugging by RhodiumToad on #postgresql led to the following
>>> observation: The error occurs only when the "SELECT ... WHERE i = a_bar();"
>>> is being planned, not when it is being executed, with the snapsho
scanf :)
I have also added a couple of additional test cases in the same diff, although
the code could still use a few more for possible corner cases etc.
Regards,
Matthijs Bomhoff
mac_parser.diff
Description: Binary data
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Jun 6, 2011, at 4:31 PM, Tom Lane wrote:
> Matthijs Bomhoff writes:
>> The attached version also rejects MACs containing additional
>> whitespace between the octets and separators etc.
>
> I was under the impression that allowing whitespace there was a feature,
> n
till somehow referenced by the
result value, even though the table itself has been dropped by the time the
result value is used.
I have tested this myself on 8.4.4 and it has also been verified on a 9.1 by
someone on #postgresql.
Kind regards,
Matthijs Bomhoff
CREATE OR REPLACE FUNCTION f
On Jun 29, 2011, at 6:03 PM, Alvaro Herrera wrote:
> Excerpts from Matthijs Bomhoff's message of mié jun 29 07:40:07 -0400 2011:
>
>> CREATE OR REPLACE FUNCTION foo(size_ INTEGER) RETURNS TEXT AS $EOF$
>> DECLARE
>> acc_ TEXT := '';
>> cur_rec_ RECORD;
>> BEGIN
>> EXECUTE 'CREATE TEMPORARY TA
