Re: Strange RETURN NEXT behaviour in Postgres 8.0 - Mailing list pgsql-hackers
From | Sergey E. Koposov |
---|---|
Subject | Re: Strange RETURN NEXT behaviour in Postgres 8.0 |
Date | |
Msg-id | Pine.LNX.4.44.0502162334280.25847-100000@lnfm1.sai.msu.ru Whole thread Raw |
In response to | Re: Strange RETURN NEXT behaviour in Postgres 8.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Strange RETURN NEXT behaviour in Postgres 8.0
|
List | pgsql-hackers |
> > For the real functions which I use, instead of > > > query = ''SELECT * FROM usno''; > > > I have > > > query = my_C_function(some_args); > > Oh? I'd make a small side bet that the underlying error is in your C > function --- possibly it's tromping on some data structure and the > damage doesn't have an effect till later. If you can demonstrate the > problem without using any custom C functions then I'd be interested to > see a test case. I want to clarify, that I have a problem even without my C functions!! And show the full exact(but long) test case, which I performed just now specially. I begin from table usno with 500 millions records wsdb=# \d usno Table "public.usno"Column | Type | Modifiers --------+--------+-----------ra | real | dec | real | bmag | real | rmag | real | ipix | bigint | errbox| box | Indexes: "box_ind" rtree (errbox) "ipix_ind" btree (ipix) "radec_ind" btree (ra, "dec") The declaration of the functions: CREATE OR REPLACE FUNCTION xxx(refcursor) RETURNS refcursor AS ' DECLARE query varchar; BEGIN query = ''SELECT * FROM usno''; OPEN $1 FOR EXECUTE query; RETURN $1; END; ' LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION yyy() RETURNS SETOF usno AS ' DECLARE rec record; DECLARE cur refcursor; BEGIN cur=xxx(''curs_name''); LOOP FETCH cur into rec; EXIT WHEN NOT FOUND; RETURN NEXT rec; END LOOP; RETURN; END; ' LANGUAGE plpgsql; wsdb=# \i q3c.sql CREATE FUNCTION CREATE FUNCTION wsdb=# select * from yyy(); ERROR: wrong record type supplied in RETURN NEXT CONTEXT: PL/pgSQL function "yyy" line 10 at return next We see the error ############################################# Now with q3c table instead of unso wsdb=# \d q3c Table "public.q3c"Column | Type | Modifiers --------+--------+-----------ra | real | dec | real | bmag | real | rmag | real | ipix | bigint | errbox| box | Indexes: "box_ind1" rtree (errbox) "ipix_ind1" btree (ipix) "radec_ind1" btree (ra, "dec") That table is not empty but filled by random numbers wsdb=# select * from q3c;ra | dec | bmag | rmag | ipix | errbox ----+-----+------+------+------+------------- 3 | 3 | 4 | 5 | 55 | (5,6),(3,4) 4 | 5 | 6 | 5 | 33 | (3,4),(1,2) (2 rows) Now the changed functions (notice, the only difference is replacing all occurencies of "usno" to "q3c") CREATE OR REPLACE FUNCTION xxx(refcursor) RETURNS refcursor AS ' DECLARE query varchar; BEGIN query = ''SELECT * FROM q3c''; OPEN $1 FOR EXECUTE query; RETURN $1; END; ' LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION yyy() RETURNS SETOF q3c AS ' DECLARE rec record; DECLARE cur refcursor; BEGIN cur=xxx(''curs_name''); LOOP FETCH cur into rec; EXIT WHEN NOT FOUND; RETURN NEXT rec; END LOOP; RETURN; END; ' LANGUAGE plpgsql; wsdb=# drop FUNCTION yyy(); DROP FUNCTION wsdb=# \i q3c.sql CREATE FUNCTION CREATE FUNCTION wsdb=# select * from yyy();ra | dec | bmag | rmag | ipix | errbox ----+-----+------+------+------+------------- 3 | 3 | 4 | 5 | 55 | (5,6),(3,4) 4 | 5 | 6 | 5 | 33 | (3,4),(1,2) (2 rows) We don't see the error. But the only change was the change from one big table to a smaller one with the precisely same structure. ###########################################
pgsql-hackers by date: