Thread: 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