Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE |
Дата | |
Msg-id | 20200904170213.12547fb8@firost обсуждение исходный текст |
Ответ на | Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Sat, 29 Aug 2020 13:47:19 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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 > [...] Indeed. Thanks. > 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". What do you mean? Writing in configuration to not drop a relation in a function where some past computed results depend on it? > (Another idea, perhaps, might be to detoast only in volatile functions, > reasoning that a nonvolatile one can't drop the table.) Would it be possible to detoast values iif the related relation are dropped later? Regards,
В списке pgsql-bugs по дате отправления: