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 по дате отправления: