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