On Mon, Sep 26, 2016 at 1:46 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > If the class really is strictly implied by the WaitEventIdentifier, > then do we really need to supply it everywhere when calling the > various wait functions? That's going to be quite a few functions: > WaitLatch, WaitLatchOrSocket, WaitEventSetWait for now, and if some > more patches out there have legs then also ConditionVariableWait, > BarrierWait, and possibly further kinds of wait points. And then all > their call sites will have have to supply the wait class ID, even > though it is implied by the other ID. Perhaps that array that > currently holds the names should instead hold { classId, displayName } > so we could just look it up?
I considered this reverse-engineering, but arrived at the conclusion that having a flexible API mattered more to give more flexibility to module developers. In short this avoids having extra class IDs like ActivityExtention, TimeoutExtension, etc. But perhaps that's just a matter of taste.. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers