On Mon, Nov 4, 2024 at 4:19 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > On 2024-Nov-04, Alexander Korotkov wrote: > > > On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier <mich...@paquier.xyz> wrote: > > > > Using output parameters in a procedure is something I did not recall. > > > Based on your point about not using a function due your argument based > > > on the snapshots, let's just use that and forget about the status > > > function entirely (please?). > > > > Please, check [1]. Usage of output parameters is a bit awkward too, > > because you need to pass some value in there. And more importantly, > > usage of output parameters also causes snapshot problem, as it causes > > another snapshot to be held. > > I wonder if it would be better to go back to the original idea of using > special DDL syntax rather than a procedure. It seems we've been piling > up hacks to get around the behavior of procedures, and we seem to have > grown one more to handle repeatable read transactions. > > It's looking to me like there's just too much cruft in the quest to > avoid having to reach consensus on new syntax. This might be a mistake. > Is it possible to backtrack on that decision?
Before committing pg_wal_replay_wait() I was under impression that stored procedure would require the same amount of efforts than utility statement to make backend "snapshot-less". However, it appears that if we have implicit REPEATABLE READ transaction, stored procedure needs more efforts. That makes the whole decision, at least, questionable. ------ Regards, Alexander Korotkov Supabase
