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  (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #16594: DROP INDEX CONCURRENTLY fails on partitioned table with a non helpful error message.
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: BUG #16592: websearch_to_tsquery() returns queries that don't result in expected matches