On Fri, Sep 11, 2015 at 12:12 AM, Bruce Momjian <br...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
