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.
