| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Wrong results from function that selects from vier after "created or replace" |
| Date: | 2020-10-13 00:38:10 |
| Message-ID: | 3401031.1602549490@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Bryn Llewellyn <bryn(at)yugabyte(dot)com> writes:
> The attached self-contained testcase, "pg-bad-invalidation-bug.sql", seems to me definitely to demonstrate a bug. I've attached the spooled output as "pg-bad-invalidation-bug.txt" Do you agree that this is a bug?
No. You marked the functions as "immutable", and then you broke that
promise by changing what they'd need to output. The planner had
already inlined the original output value of f1() into the calling
expressions in f2(), on the strength of it being allegedly immutable.
There is no mechanism for undoing that (short of a forced cache flush
or session end), nor should there need to be.
If I mark the functions as either stable or volatile, I see the
desired behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2020-10-13 00:38:38 | Re: Wrong results from function that selects from vier after "created or replace" |
| Previous Message | Michael Paquier | 2020-10-13 00:25:07 | Re: BUG #15858: could not stat file - over 4GB |