Re: pageinspect: add tuple_data_record()
От | Andres Freund |
---|---|
Тема | Re: pageinspect: add tuple_data_record() |
Дата | |
Msg-id | 20181017014659.kfupelhk54ttskmg@alap3.anarazel.de обсуждение исходный текст |
Ответ на | pageinspect: add tuple_data_record() (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: pageinspect: add tuple_data_record()
|
Список | pgsql-hackers |
Hi, On 2018-10-16 21:39:02 -0400, James Coleman wrote: > Background: > In my usage of pageinspect for debugging or other purposes I often find it > frustrating that I don't have a way to easily view a heap page's tuple data > as actual records rather than binary data. After encountering this again > last week while doing some data recovery after an accidental delete (and > manually parsing a few int and timestamp fields with get_byte magic) I > decided to write up a patch to add a function to handle this case. > Summary: > The new function tuple_data_record() parallels the existing > tuple_data_split() function, but instead of returning a bytea array of raw > attribute heap values, it returns a row type of the relation being examined. I don't think it's entirely safe to do so for invisible rows. The toast references could be reused, constraints be violated, etc. So while I could have used this several times before, it's also very likely a good way to cause trouble. It'd probably be ok to just fetch the binary value of the columns, but detoasting sure ain't ok. > This is my first patch submission, so I encountered a few questions that > the coding style docs didn't seem to address, like whether it's preferable > to line up variable declarations by name. There's ./src/tools/pgindent/pgindent (which needs an external dep), to do that kind of thing... Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: