At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in > Anna Akenteva <a.akent...@postgrespro.ru> writes: > > I'd like to hear others' opinions on the syntax as well. > > Pardon me for coming very late to the party, but it seems like there are > other questions that ought to be answered before we worry about any of > this. Why is this getting grafted onto BEGIN/START TRANSACTION in the > first place? It seems like it would be just as useful as a separate > command, if not more so. You could always start a transaction just > after waiting. Conversely, there might be reasons to want to wait > within an already-started transaction. > > If it could survive as a separate command, then I'd humbly suggest > that it requires no grammar work at all. You could just invent one > or more functions that take suitable parameters.
The rationale for not being a fmgr function is stated in the following comments. https://www.postgresql.org/message-id/CAEepm%3D0V74EApmfv%3DMGZa24Ac_pV1vGrp3Ovnv-3rUXwxu9epg%40mail.gmail.com | because it doesn't work for our 2 higher isolation levels as | mentioned." https://www.postgresql.org/message-id/CA%2BTgmob-aG3Lqh6OpvMDYTNR5eyq94VugyEejyk7pLhE9uwnyA%40mail.gmail.com | IMHO, trying to do this using a function-based interface is a really | bad idea for exactly the reasons you mention. I don't see why we'd | resist the idea of core syntax here; transactions are a core part of | PostgreSQL. It seemed to me that they were suggested it to be in a part of BEGIN command, but the next proposed patch implemented "WAIT FOR" command for uncertain reasons to me. I don't object to the isolate command if it is useful than a part of BEGIN command. By the way, for example, pg_current_wal_lsn() is a volatile function and repeated calls within a SERIALIZABLE transaction can return different values. If there's no necessity for this feature to be a core command, I think I would like to be it a function. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
