Re: pageinspect patch, for showing tuple data

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Nikolay Shaplov <n(dot)shaplov(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pageinspect patch, for showing tuple data
Date: 2015-09-11 06:19:10
Message-ID: CAB7nPqSLVV=+Aw_--TfhCY-Fmp3QJ9=V+2D4AvxfaasVP+sLnw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 11, 2015 at 12:12 AM, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-09-11 07:08:25 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Michael Paquier 2015-09-11 06:12:04 Re: pageinspect patch, for showing tuple data