On Thu, Mar 8, 2018 at 7:54 AM, Pavan Deolasee <pavan.deola...@gmail.com> wrote:
>> > + /*
>> > + * 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 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.
>
> I removed this code since it was wrong. We might want to add some basic
> checks for existence of volatile functions in the WHEN or SET clauses. But I
> agree, it's no different than regular UPDATEs. So may be not a big deal.
I just caught up on this thread. I'm definitely glad to see that code
go because, wow, that is all kinds of wrong. I don't see a real need
to add any kind of replacement check, either. Prohibiting volatile
functions here doesn't seem likely to accomplish anything useful. It
seems like the most we'd want to do is mention this the documentation
somehow, and I'm not even sure we really need to do that much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
