On 2022-Nov-16, Alvaro Herrera wrote:
> Hmm, good find. As I recall, I was opposed to the idea of throwing an
> error if the WHEN expression writes to the database, and the previous
> implementation had some hole, so I just ripped it out after discussing
> it; but I evidently failed to notice this test case about it.
Ah, I found out what happened, and my memory as usual is betraying me.
This was changed before I was involved with the patch at all: Pavan
changed it between his v18[1] and v19[2]:
if (action->whenqual)
{
- int64 startWAL = GetXactWALBytes();
- bool qual = ExecQual(action->whenqual, econtext);
-
- /*
- * SQL Standard says that WHEN AND conditions must not
- * write to the database, so check we haven't written
- * any WAL during the test. Very sensible that is, since
- * we can end up evaluating some tests multiple times if
- * we have concurrent activity and complex WHEN clauses.
- *
- * XXX If we had some clear form of functional labelling
- * we could use that, if we trusted it.
- */
- if (startWAL < GetXactWALBytes())
- ereport(ERROR,
- (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
- errmsg("cannot write to database within WHEN AND
condition")));
This is what Peter Geoghegan had to say about it at the time:
> This needs to go. Apart from the fact that GetXactWALBytes() is buggy
> (it returns int64 for the unsigned type XLogRecPtr), the whole idea
> just seems unnecessary. I don't see why this is any different to using
> a volatile function in a regular UPDATE.
Pavan just forgot to remove the test. I'll do so now.
[1]
https://postgr.es/m/CABOikdPFCcgp7=zoN4M=y0tefw4q9dpau+oy5jn5a+hwydn...@mail.gmail.com
[2]
https://postgr.es/m/caboikdouoaxt1h885tc_ca1loereejqdvdzqg62rqkizppy...@mail.gmail.com
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"No tengo por qué estar de acuerdo con lo que pienso"
(Carlos Caszeli)
