Re: [PATCH] add relation and block-level filtering to pg_waldump
От | Peter Eisentraut |
---|---|
Тема | Re: [PATCH] add relation and block-level filtering to pg_waldump |
Дата | |
Msg-id | 3a4c2e93-7976-2320-fc0a-32097fe148a7@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH] add relation and block-level filtering to pg_waldump (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: [PATCH] add relation and block-level filtering to pg_waldump
|
Список | pgsql-hackers |
On 24.03.22 11:57, Peter Eisentraut wrote: > On 23.03.22 23:54, Thomas Munro wrote: >>> That's because ForkNum is a signed type. You will probably succeed if >>> you use "%d" instead. >> >> Erm, is that really OK? C says "Each enumerated type shall be >> compatible with char, a signed integer type, or an >> unsigned integer type. The choice of type is implementation-defined, >> but shall be capable of representing the values of all the members of >> the enumeration." It could even legally vary from enum to enum, >> though in practice most compilers probably just use ints all the time >> unless you use weird pragma pack incantation. Therefore I think you >> need an intermediate variable with the size and signedness matching the >> format string, if you're going to scanf directly into it, which >> David's V6 did. > > An intermediate variable is probably the best way to avoid thinking > about this much more. ;-) But note that the committed patch uses a %u > format whereas the ForkNum enum is signed. > > Btw., why the sscanf() instead of just strtol/stroul? Or even: Why are we exposing fork *numbers* in the user interface? Even low-level tools such as pageinspect use fork *names* in their interface.
В списке pgsql-hackers по дате отправления: