Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYBcx-0002Iy-Bf for pgsql-admin@arkaria.postgresql.org; Wed, 27 Jun 2018 14:40:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fYBcv-0002eO-0D for pgsql-admin@arkaria.postgresql.org; Wed, 27 Jun 2018 14:40:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYBcu-0002eH-LJ for pgsql-admin@lists.postgresql.org; Wed, 27 Jun 2018 14:40:56 +0000 Received: from mail-fw.wtccommunications.ca ([66.102.92.155]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fYBcs-0007eu-0S for pgsql-admin@lists.postgresql.org; Wed, 27 Jun 2018 14:40:55 +0000 X-ASG-Debug-ID: 1530110452-08fa0341c053830001-e2Aq3s Received: from mail2.kingston.net (mail2.kingston.net [66.102.92.5]) by mail-fw.wtccommunications.ca with ESMTP id nMT4tKQ4QzhsrIK7 for ; Wed, 27 Jun 2018 10:40:52 -0400 (EDT) X-Barracuda-Envelope-From: colbec@kingston.net X-Barracuda-Effective-Source-IP: mail2.kingston.net[66.102.92.5] X-Barracuda-Apparent-Source-IP: 66.102.92.5 Received: from [192.168.0.111] (dynamic-66-102-72-178.wtccommunications.ca [66.102.72.178]) (authenticated bits=0) by mail2.kingston.net (8.14.4/8.14.4/Debian-4) with ESMTP id w5REenoS019727 for ; Wed, 27 Jun 2018 10:40:52 -0400 To: pgsql-admin@lists.postgresql.org From: Colin Beckingham Subject: Bytea data in SQL output pane Message-ID: X-ASG-Orig-Subj: Bytea data in SQL output pane Date: Wed, 27 Jun 2018 10:40:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Barracuda-Connect: mail2.kingston.net[66.102.92.5] X-Barracuda-Start-Time: 1530110452 X-Barracuda-URL: https://mail-fw.wtccommunications.ca:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at wtccommunications.ca X-Barracuda-Scan-Msg-Size: 704 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.52450 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Currently any bytea fields are rendered as "[binary data]" in SQL output pane. From the archive I found a message that evidently there was very high processor load in trying to show the data. I guess the solution at the time was not to render the data at all. Bytea is used a lot in crypto, an example is blockchain hashes. It is handy to be able to see that hashes end up in the right record and right column. A workaround is to use pgphpadmin which reveals the correct codes, and as long as we use the now (Postgresql 10) non-default 'escape' encoding and not the default 'hex' the data is visible in the REPL as well. Just wondering where this issue sits in the TODO list if any?