Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE
| От | Tom Lane |
|---|---|
| Тема | Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE |
| Дата | |
| Msg-id | 3568911.1598723239@sss.pgh.pa.us обсуждение |
| Ответ на | [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>) |
| Ответы |
Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE
|
| Список | pgsql-bugs |
Jehan-Guillaume de Rorthais <jgdr@dalibo.com> writes:
> We discovered a bug in plpgsql.
> When using RETURN QUERY on a relation with some toasted values and when this
> relaiton is later dropped or truncated, an error is raised at the end of the
> function.
This isn't particularly RETURN QUERY's fault; there are any number of ways
to produce the same sort of error. I reproduced it with
declare r record;
...
for r in SELECT str FROM temp_rel loop
return next r.str;
end loop;
as well as
declare r record;
...
SELECT str INTO r FROM temp_rel LIMIT 1;
DROP TABLE temp_rel;
--TRUNCATE TABLE temp_rel;
return r.str;
I guess we could forcibly detoast values in enough places to close all the
gaps, but the performance costs might be annoying. I think a case can
definitely be made for saying "don't do that".
(Another idea, perhaps, might be to detoast only in volatile functions,
reasoning that a nonvolatile one can't drop the table.)
regards, tom lane
В списке pgsql-bugs по дате отправления: