Обсуждение: Re: [GENERAL] setof record "out" syntax and returning records

This thread made me try this example.  Note that there's a WARNING in the spot
where I pressed tab.

alvherre=# create or replace function foo (out pg_class) language plpgsql as $$ declare i pg_class%rowtype; begin for i
inselect * from pg_class loop return next; end loop; end; $$;
 
ERROR:  cannot use RETURN NEXT in a non-SETOF function en o cerca de «next»
LINEA 1: ...begin for i in select * from pg_class loop return next; end ...
               ^
 
alvherre=# set lc_messWARNING:  problem in alloc set PL/PgSQL function context: detected write past chunk end in block
0xb541d0,chunk 0xb562c0
 
ages to 'C';
WARNING:  problem in alloc set PL/PgSQL function context: detected write past chunk en
d in block 0xb541d0, chunk 0xb562c0
SET


The reason I tried to change lc_messages is that the spanish message
struck me as a bit odd and wanted to see what the english message looked
like.

The full sequence required to create the message in a clean backend, regardless
of whether the foo(pg_class) function exists previously, is:

create function foo (out pg_class) language plpgsql as $$ declare i pg_class%type; begin for i in select * from
pg_classloop return next; end loop; end; $$;
 
create or replace function foo (out pg_class) language plpgsql as $$ declare i pg_class%type; begin for i in select *
frompg_class loop return next; end loop; end; $$;
 
create or replace function foo (out pg_class) language plpgsql as $$ declare i pg_class%rowtype; begin for i in select
*from pg_class loop return next; end loop ; end; $$;
 
set lc_mess    <tab>

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:
> alvherre=# set lc_messWARNING:  problem in alloc set PL/PgSQL function context: detected write past chunk end in
block0xb541d0, chunk 0xb562c0
 
> ages to 'C';
> WARNING:  problem in alloc set PL/PgSQL function context: detected write past chunk en
> d in block 0xb541d0, chunk 0xb562c0
> SET

Ugh.  I could not reproduce this here though; there's some missing bit
of context.  Are you testing CVS HEAD?  I assume you've got --enable-nls
on, but what were the initial settings of lc_messages, the server
locale, and the database encoding?
        regards, tom lane

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > alvherre=# set lc_messWARNING:  problem in alloc set PL/PgSQL function context: detected write past chunk end in
block0xb541d0, chunk 0xb562c0
 
> > ages to 'C';
> > WARNING:  problem in alloc set PL/PgSQL function context: detected write past chunk en
> > d in block 0xb541d0, chunk 0xb562c0
> > SET
> 
> Ugh.  I could not reproduce this here though; there's some missing bit
> of context.  Are you testing CVS HEAD?  I assume you've got --enable-nls
> on, but what were the initial settings of lc_messages, the server
> locale, and the database encoding?

False alarm, I think.  I cleaned and rebuilt and now I can't reproduce it.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> False alarm, I think.  I cleaned and rebuilt and now I can't reproduce it.

Strange.  Most of the time I'd have no problem writing this off as a
build-synchronization error, but the tree has been so quiet lately due
to the release cycle that this seems an odd time to be seeing such a
problem.  I did a quick look through the CVS logs and couldn't find any
plausible-looking causes since the start of the year; except maybe this:

http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/relscan.h.diff?r1=1.59;r2=1.60;f=h

but alignment rules should have meant that that didn't really move any
of the other fields.

Anyway, if it went away on a clean rebuild, seems that a stale .o file
must be the explanation.  Do you normally use --enable-depend?
        regards, tom lane

Tom Lane wrote:

> Strange.  Most of the time I'd have no problem writing this off as a
> build-synchronization error, but the tree has been so quiet lately due
> to the release cycle that this seems an odd time to be seeing such a
> problem.

This was on a laptop I hadn't used in some time, and I think I must have
done "make install" in, for example, src/backend only.  Normally, I use
my do-it-all script which zaps the entire install tree, but sometimes I
don't.

> Anyway, if it went away on a clean rebuild, seems that a stale .o file
> must be the explanation.  Do you normally use --enable-depend?

Yes.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Strange.  Most of the time I'd have no problem writing this off as a
>> build-synchronization error, but the tree has been so quiet lately due
>> to the release cycle that this seems an odd time to be seeing such a
>> problem.

> This was on a laptop I hadn't used in some time, and I think I must have
> done "make install" in, for example, src/backend only.

Ah.  That could explain it, if you had a plpgsql.so that was quite out
of date compared to the backend.  OK, then I'm prepared to forget about
this one ...
        regards, tom lane