| From: | chap(at)anastigmatix(dot)net |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: When IMMUTABLE is not. |
| Date: | 2023-06-15 14:25:46 |
| Message-ID: | 7d1504b9211a5c153491761f3d82ae53@anastigmatix.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2023-06-15 10:19, David G. Johnston wrote:
> The failure to find and execute the function code itself is not a
> failure
> mode that these markers need be concerned with. Assuming one can
> execute
> the function an immutable function will give the same answer for the
> same
> input for all time.
That was the view I ultimately took, and just made PL/Java suppress that
SPI readonly flag when going to look for the function code.
Until that change, you could run into the not-uncommon situation
where you've just loaded a jar of new functions and try to use them
in the same transaction, and hey presto, the VOLATILE ones all work,
and the IMMUTABLE ones aren't there yet.
Regards,
-Chap
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-06-15 14:49:01 | Re: When IMMUTABLE is not. |
| Previous Message | David G. Johnston | 2023-06-15 14:19:39 | Re: When IMMUTABLE is not. |