Re: pageinspect: add tuple_data_record()

>
>
> I did compleatly got the question... The question is it safe to split
> tuple
> record into array of raw bytea? It is quite safe from my point of view.
> We
> use only data that is inside the tuple, and info from pg_catalog that
> describes the tuple structure. So we are not affected if for example toast
> table were cleaned by vacuum. If you try to deTOAST data when TOAST table
> were
> already overwritten by new data, you can get some trouble...
>
>
The existing tuple_data_split() method already explicitly allows deTOASTing
data,
so if this is a problem, the problem already exists in pageinspect.

> I find this approach a bit wrong. pageinspect is about viewing data in raw
> mode, not about looking at the tuples that were deleted. It can be used
> for
> this task, but it has other main purpose.
>
> ...
>
> Than using these functions you can write pure sql wrapper that do what you
> really want.
>
>
It's actually extremely difficult to extract real data types from the raw
disk data in pure
SQL, which was the reason for this patch.

When using pageinspect to investigate the raw data behind a potential bug
or other issue
(for example I've used it in the past pre-9.6 to check the xmin/xmax
information to help
track down replication bugs (determining if the tuple information was there
but just not
visible after a vacuum or if the tuple data itself was missing). Even in
this kind of "under
the hood" inspection it's quite useful to be able to see actual data types
rather than binary
data.

In these kinds of use cases I believe that just ignoring TOASTed data is
even acceptable
because once you're already down the rabbit hole of looking at non-visible
information
you've already accepted that the data may no longer be complete or valid.