On 07/02/2018 05:00 AM, Dave Page wrote:
On Mon, Jul 2, 2018 at 8:43 AM, Colin Beckingham <col...@kingston.net
<mailto:col...@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.