Re: pageinspect patch, for showing tuple data
| От | Michael Paquier |
|---|---|
| Тема | Re: pageinspect patch, for showing tuple data |
| Дата | |
| Msg-id | CAB7nPqSLVV=+Aw_--TfhCY-Fmp3QJ9=V+2D4AvxfaasVP+sLnw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pageinspect patch, for showing tuple data (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
On Fri, Sep 11, 2015 at 12:12 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, Sep 10, 2015 at 03:46:25PM +0900, Michael Paquier wrote: >> Why is it not convenient at all? Yes, you have a point, we need those >> fields to be able to parse the t_data properly. Still the possibility >> to show individual fields of a tuple as a bytea array either with >> toasted or detoasted values is a concept completely different from >> simply showing the page items, which is what, it seems to me, >> heap_page_items is aimed to only do. Hence, As t_infomask2, t_infomask >> and t_bits are already available as return fields of heap_page_items, >> we should simply add a function like that: >> heap_page_item_parse(Oid relid, bytea data, t_infomask2 int, >> t_infomask int, t_bits int, bool force_detoast, warning_mode bool) >> returns bytea[] > > Should pageinspect create a table that contains some of the constants > used to interpret infomask? Interesting idea. It may be indeed useful to show to a user mappings between t_infomask flags <=> textual meaning. I guess that we could have an SRF function with a view on top of it that returns such a list. The same can apply to t_infomask2. -- Michael
В списке pgsql-hackers по дате отправления: