Re: Timeline ID hexadecimal format

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Timeline ID hexadecimal format
Дата
Msg-id CAM-w4HPnR=y3-FVY9YJvDUA=-hJPSN70yW9c0yeDvy2nHO-rVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Timeline ID hexadecimal format  (Sébastien Lardière <sebastien@lardiere.net>)
Ответы Re: Timeline ID hexadecimal format  (Sébastien Lardière <sebastien@lardiere.net>)
Re: Timeline ID hexadecimal format  (Sébastien Lardière <sebastien@lardiere.net>)
Re: Timeline ID hexadecimal format  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
I actually find it kind of annoying that we use hex strings for a lot
of things where they don't add any value. Namely Transaction ID and
LSNs. As a result it's always a bit of a pain to ingest these in other
tools or do arithmetic on them. Neither is referring to memory or
anything where powers of 2 are significant so it really doesn't buy
anything in making them easier to interpret either.

I don't see any advantage in converting every place where we refer to
timelines into hex and then having to refer to things like timeline
1A. It doesn't seem any more intuitive to someone understanding what's
going on than referring to timeline 26.

The fact that the *filename* has it encoded in hex is an
implementation detail and really gets exposed here because it's giving
you the underlying system error that caused the problem. The confusion
only arises when the two are juxtaposed. A hint or something just in
that case might be enough?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Clarify deleting comments and security labels in synopsis
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: [PATCH] Fix old thinko in formula to compute sweight in numeric_sqrt().