At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> Anna Akenteva <a.akenteva@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
