xlog file naming

Isn't the naming of the xlog files slightly bogus?

We have the following sequence:

00000001000008D0000000FD
00000001000008D0000000FE
00000001000008D100000000

Ignoring that we skip FF for some obscure reason (*), these are
effectively supposed to be 64-bit numbers, chunked into 16MB pieces, so
shouldn't the naming be

00000001000008D0FD000000
00000001000008D0FE000000
00000001000008D100000000

Then a lot of other things would also start making more sense:

The backup file

00000001000008D1000000C9.00013758.backup

should really be

00000001000008D1C9013758.backup

(At least conceptually. It's debatable whether we'd want to change
that, since as it is, it's convenient to detect the preceding WAL file
name by cutting off the end. OTOH, it's safer to actually look into the
backup file for that information.)

The return value of pg_start_backup that currently looks something like

pg_start_backup
-----------------
8D1/C9013758

should really be

000008D1C9013758

(perhaps the timeline should be included?)

and similarly, log output and pg_controldata output like

Latest checkpoint location: 8D3/5A1BB578

should be

Latest checkpoint location: 000008D35A1BB578

Then all instances of xlog location would look the same.

Also, the documentation offers this example:

"For example, if the starting WAL file is 0000000100001234000055CD the
backup history file will be named something like
0000000100001234000055CD.007C9330.backup."

Both the WAL and the backup file names used here are actually
impossible, and are not helping to clarify the issue.

It seems to me that this is all uselessly complicated and confused.

(*) - That idea appears to come from the same aboriginal confusion about
WAL "files" vs "segments" vs WAL position. Unless we support WAL
segments of size 1 or 2 bytes, there shouldn't be any risk of
overflowing the segment counter.

PS2: While we're discussing the cleanup of xlog.c, someone daring could
replace XLogRecPtr by a plain uint64 and possibly save hundres of lines
of code and eliminate a lot of the above confusion.