From: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: [BUG] plpgsql RETURN QUERY with toasted fields -vs- DROP/TRUNCATE |
Date: | 2020-09-04 15:02:13 |
Message-ID: | 20200904170213.12547fb8@firost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, 29 Aug 2020 13:47:19 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)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,
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-09-04 19:45:36 | Re: BUG #16419: wrong parsing BC year in to_date() function |
Previous Message | Jehan-Guillaume de Rorthais | 2020-09-04 14:56:58 | Re: [BUG v13] Crash with event trigger in extension |