> > > 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.
