Our naming of wait events is a disaster.

I've been trying to reformat table 27.4 (wait events) to fit
into PDF output, which has caused me to study its contents
more than I ever had before.  The lack of consistency, or
even any weak attempt at consistency, is not just glaring;
it's embarrassing.

We have a lot of wait event names like these:

	XidGenLock
	ProcArrayLock
	SInvalReadLock
	SInvalWriteLock
	WALBufMappingLock
	WALWriteLock

which are more or less fine; maybe one could wish for having
just one way of capitalizing acronyms not two, but I'll let
that pass.  But could we be satisfied with handling all multi
word names in that style?  Nope:

	commit_timestamp
	multixact_offset
	multixact_member
	wal_insert

(and in case you are wondering, yes, "WAL" is also spelled "Wal"
in yet other places.)

And then somebody else, unwilling to use either of those styles,
thought it would be cute to do

	Hash/Batch/Allocating
	Hash/Batch/Electing
	Hash/Batch/Loading
	Hash/GrowBatches/Allocating

and all alone in the remotest stretch of left field, we've got

	speculative token

(yes, with a space in it).

Also, while the average length of these names exceeds 16 characters,
with such gems as SerializablePredicateLockListLock, think not that
prolixity is the uniform rule:

	oldserxid
	proc
	tbm

Is it unreasonable of me to think that there should be *some*
amount of editorial control over these user-visible names?
At the rock bottom minimum, shouldn't we insist that they all
be legal identifiers?

I'm not sure what our stance is on version-to-version consistency
of these names, but I'd like to think that we are not stuck for
all time with the results of these random coin tosses.

My inclination is to propose that we settle on the first style
shown above, which is the majority case now, and rename the
other events to fit that.  As long as we're breaking compatibility
anyway, I'd also like to shorten one or two of the very longest
names, because they're just giving me fits in fixing the PDF
rendering.  (They would make a mess of the display of
pg_stat_activity, too, anytime they come up in the field.)

Thoughts?

			regards, tom lane