Обсуждение: Bytea as "Binary Data"

Currently pgadmin4 displays bytea fields as "[Binary Data]".

In searching the archives for the reason for this, I found some 
discussion on lengthy processing slowing down display. So a decision was 
made to not attempt to display the data at all, and since the data can 
be lengthy this makes some sense.

While such binary data is not "readable", in the era of SHA hashes it is 
useful to be able to visually check that the right hash is in the right 
column using the first few text characters. We can of course do this in 
the Postgresql REPL or even in the old phpPgAdmin which usefully 
displays part of the 'escape' translation of the hash.

Is there some concrete reason for not displaying such data, or is the 
community open to revealing a short stub which would be more helpful 
than no representation at all? Thanks.

On Mon, Jul 2, 2018 at 8:43 AM, Colin Beckingham <colbec@kingston.net> wrote:

Currently pgadmin4 displays bytea fields as "[Binary Data]".

In searching the archives for the reason for this, I found some discussion on lengthy processing slowing down display. So a decision was made to not attempt to display the data at all, and since the data can be lengthy this makes some sense.

While such binary data is not "readable", in the era of SHA hashes it is useful to be able to visually check that the right hash is in the right column using the first few text characters. We can of course do this in the Postgresql REPL or even in the old phpPgAdmin which usefully displays part of the 'escape' translation of the hash.

Is there some concrete reason for not displaying such data, or is the community open to revealing a short stub which would be more helpful than no representation at all? Thanks.

I'm not opposed to showing something more useful than "[Binary Data]". The question is, what exactly? In many cases it'll likely be unreadable garbage.

FYI, eventually I'd like to be able to try to detect the data type, so if we find it's actually an image for example, we can display it (and potentially have an editor cell that allows you to replace it). 

Yes, it is very context-dependent since binary can represent anything, a file, an image, a sound, and in my current use case a hash. The issue is to visually check that the right repeated hash has ended up in the right column and right record/row; just a few characters followed by an ellipsis would be enough to accomplish this since a repetition of the first say 6 characters would be extremely rare. In this specific case, replacement of a hash, the ability to edit would probably be detrimental; in my case it is either right or wrong and if wrong would be a matter of rebuilding, not editing.