Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aKvWq-0005AL-Hm for pgsql-sql@arkaria.postgresql.org; Sun, 17 Jan 2016 22:10:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aKvWq-0001YK-4f for pgsql-sql@arkaria.postgresql.org; Sun, 17 Jan 2016 22:10:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aKvVq-0000Og-HE for pgsql-sql@postgresql.org; Sun, 17 Jan 2016 22:09:30 +0000 Received: from post.visena.com ([46.226.10.50]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aKvVm-0005gs-PZ for pgsql-sql@postgresql.org; Sun, 17 Jan 2016 22:09:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=visena.com; s=20141101.wh; h=Content-Type:MIME-Version:Subject:In-Reply-To:Message-ID:To:From:Date; bh=4vJv8N8MKRUwcV6GPxzo6aoT05H5yvtlSF8o3PgnTbE=; b=oEQa6bdHbtQNKjzNvn5PF7xIKLDxnzXlDPV2dg4ywl+z2xLk5MqwPP6v7R1KvAgEGnoeXEeNKaBFsXVczr5bM10d1TkhaAWoQaR679AgcLHAJnnSh2lgNj9zZLvQB2SYi50NDn/Wm1pg2c5GEgmN8vuhqhi9n1iPSPvpjd3wp9Y=; Received: from [10.0.1.10] (helo=tc7-visena.wh.internal.visena.com) by post.visena.com with esmtp (Exim 4.82) (envelope-from ) id 1aKvVj-0007Bx-U1 for pgsql-sql@postgresql.org; Sun, 17 Jan 2016 23:09:26 +0100 Received: from localhost ([127.0.0.1] helo=tc7-visena.wh.internal.visena.com) by tc7-visena.wh.internal.visena.com with esmtp (Exim 4.82) (envelope-from ) id 1aKvVj-0004eo-Sy for pgsql-sql@postgresql.org; Sun, 17 Jan 2016 23:09:23 +0100 Date: Sun, 17 Jan 2016 23:09:23 +0100 (CET) From: Andreas Joseph Krogh To: pgsql-sql@postgresql.org Message-ID: In-Reply-To: <569BF994.1060909@aklaver.com> Subject: Re: BYTEA MIME-Version: 1.0 X-Mailer: Visena Mail 2.0.0-SNAPSHOT X-Spam-Score: 0.6 X-Spam-Report: SpamAssasin (score=0.6, required 5.0 ALL_TRUSTED=-1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=1.625) X-Pg-Spam-Score: -0.5 (/) Content-Type: multipart/related; boundary="----=_Part_736_42316034.1453068563837" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org ------=_Part_735_40563649.1453068563837 Content-Type: multipart/related; boundary="----=_Part_736_42316034.1453068563837" ------=_Part_736_42316034.1453068563837 Content-Type: multipart/alternative; boundary="----=_Part_737_1653637719.1453068563851" ------=_Part_737_1653637719.1453068563851 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 s=C3=B8ndag 17. januar 2016 kl. 21:29:08, skrev Adrian Klaver < adrian.klaver@aklaver.com >: On 01/17/2016 11:33 AM, Eugene Yin wrote: > Pg 9.4+ > > Storing binary data using bytea > or text > data > types > >=C2=A0 =C2=A0* Pluses >=C2=A0 =C2=A0 =C2=A0 =C2=A0o Storing and Accessing entry utilizes the sam= e interface when >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accessing any other data type or record= . >=C2=A0 =C2=A0 =C2=A0 =C2=A0o No need to track OID of a "large object" you= create >=C2=A0 =C2=A0* Minus >=C2=A0 =C2=A0 =C2=A0 =C2=A0o bytea and text data type both use TOAST >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(details here ) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ limited to 1G per entry >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ 4 Billion (> 2KB) entries per = table max >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. >=C2=A0 =C2=A0 =C2=A0 =C2=A0o *Need to escape/encode binary data before se= nding to DB then do >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the reverse after retrieving the data * >=C2=A0 =C2=A0 =C2=A0 =C2=A0o Memory requirements on the server can be ste= ep even on a small >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0record set. > > https://wiki.postgresql.org/wiki/BinaryFilesInDB > > > > Do I=C2=A0 really *Need to escape/encode binary data before sending to D= B > then do the reverse after retrieving the data?* > * > * > If so, what (*Java*) codes should I use to achieve this goal (I am using > the Java to interface with the DB)? https://jdbc.postgresql.org/documentation/94/binary-data.html =C2=A0 Save yourself the trouble and don't go this route. Use=20 https://github.com/impossibl/pgjdbc-ng instead. =C2=A0 -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andreas@visena.com www.visena.com =C2=A0 ------=_Part_737_1653637719.1453068563851 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P=C3=A5 s=C3=B8ndag 17. januar 2016 kl. 21:29:08, skrev Adrian Klaver = <adrian.klaver@aklaver.com<= /a>>:
On = 01/17/2016 11:33 AM, Eugene Yin wrote:
> Pg 9.4+
>
> Storing binary data using bytea
> <http://www.postgresql.org/docs/8.4/static/datatype-binary.html>= or text
> <http://www.postgresql.org/docs/8.4/static/datatype-character.html&= gt; data
> types
>
>=C2=A0 =C2=A0* Pluses
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o Storing and Accessing entry utilizes the s= ame interface when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accessing any other data type or reco= rd.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o No need to track OID of a "large obje= ct" you create
>=C2=A0 =C2=A0* Minus
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o bytea and text data type both use TOAST >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.postgresql.org/docs/8.= 4/static/storage-toast.html>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(details here <https://wiki.postgr= esql.org/wiki/TOAST>)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ limited to 1G per entry
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+ 4 Billion (> 2KB) entries= per table max
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://wiki.postgr= esql.org/wiki/TOAST>.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o *Need to escape/encode binary data before = sending to DB then do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the reverse after retrieving the data= *
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o Memory requirements on the server can be s= teep even on a small
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0record set.
>
> https://wiki.postgresql.org/wiki/BinaryFilesInDB
>
>
>
> Do I=C2=A0 really *Need to escape/encode binary data before sending to= DB
> then do the reverse after retrieving the data?*
> *
> *
> If so, what (*Java*) codes should I use to achieve this goal (I am usi= ng
> the Java to interface with the DB)?

https://jdbc.postgresql.org/documentation/94/binary-data.html
=C2=A0
Save yourself the trouble and don't go this route. Use https://github.= com/impossibl/pgjdbc-ng instead.
=C2=A0
=C2=A0
------=_Part_737_1653637719.1453068563851-- ------=_Part_736_42316034.1453068563837 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Disposition: inline Content-ID: iVBORw0KGgoAAAANSUhEUgAAAIUAAAAYCAYAAADUIj6hAAAABHNCSVQICAgIfAhkiAAABzBJREFU aEPtmNFxHDcMhmVP3i1VECpvnjzkVIHWFfhcgVcVRKrAUgWRK/C6Al8H3lTgy0PGbzFdQc4VJP/H ADs43q6kROeJNbOYgQACIAgCWJKng4MZ5gxUGXh0U0b+SIuF9G+EWXj2Q15vbrE/NPtk9uub7Gfd t5mBx1NhqSEo8HshjbEUtlO2yIM9tsx5dZP9rPt2MzDZFAqZE4LGcFjdsg3saQaHt7fY70X949On aS+OZidDBkavD33157L4xaw2os+Mp/DAC10l2XhOCeStj0W5ajrJL8WfCi80Xgf9vVlrhg9yRONe /f7xI2vNsIcM7JwU9o6oGyJrLT8JOA1aX9sKP4wl94bAniukEbo/n7YPmuTETzIab4Y9ZWCrKexd 8M58lxPCvvD6aihfvexbEQoPYO8NQRO0JnddGO6FJYaVsBde7cXj7KRk4LsqDxQzCYeGsJNgaXZe +JXkyGgWINq3Gp+bHNILz+wEYs5qH1eJrouNrpDXtk4O6x1IvtD40GWyJYYdkF0jIbYZlN16xygI gl9smbMDsmFdfAKb23xGB8H/mv3tOJfArs1kukk79DEPdQ5u0g1vCvvqKXIW8mZYW+F3Tg4r8HvZ kQCCLydK8EFMQCe5N8RgL9mRG0SqQFuNvdE6beSs0qPDBuCdg0+gvClso8SbTO4ki7mQzQqBrcMH QPwReg2wW8umEe/+L8T/LEzBGF9nXjzZ46s+ITHvhegW8LL39xm6App7KYL/GE+vcYnFbJiP/0aY hdiCnRC7jaj7eiK2ETInC5PRF6LYkSN0+HabF75WuT6syCyI0YkVGGMvUC33AmfZTDUEj8u6IVhu EhRUJ2U2g6UlugyNb03Hl9obHwlxJbcRzcYjO4QPjVfGFTQav4vrmp7cpMp2qbHnBxWJbisbho2Q XI6C1sIHDUFhH4Hij4UbIev66eANeiwbkA+LBsO36zAHzoXU7AhbqLAXEiOYTXcSdO8VS9L4wN8U BIYhBd6oSUgYMijOkecRuTdQa/YiBXhbXFcnCnI2SrfeBG9NydrLYMhGHa5qB9pQIxlzAE6Okjzx JO5afGe6kmhBicWKQNKuTZ5EW+MjQY8v/9rQ0bhJSJyNGUe/JH1t8h1iMbdSPAvxHYin6YmN9YBX QmTYZZNh14vHhhhal5vtcIrJjmvszPRJdExH3MWHvykoBEc9CoCGWJisOLOGoCORs1FvIMbYA8z3 kwM59oemy6LlWrLxFLmWgiQAfEGd8S+NssbK+EhyGLxUkhhiy717waBqHOJYSEacwBejkFNhjJNj v/gANOdQxPfciP/JVBCK2cOIcg3RRJ+CPrLPNVhhN6F38VKMF3XLlIJrjU5C8gMFxvKDvOcPc4rV NjCn7KM0BV+161V8viSCuJZ8SITGJGEh7IUUlxOFMYUH1kJOCN4Wh+I5pqCuK01k40kSNtnKiKIl UfxAgW5sU5JlS05rtt5YFJF1SWoqHv6BRgQcA4/bdb9WRjmMk3jyUMAbIoyJq9e4cVmgzKt9j5gN J/aYDhk+hhjExwaPcz5PObA5Zd9bvz5UzCTZuZDidu5AchpiKSwPR+TV1bCWqBQ9nCjJ5neivC82 Nr4LeS2j1gw5LUqwBuhGQQU5UwHeSslXkwIynz2U2A2yKDgG7OffwLA3TpGRpk0Tzpj3ZEJXi/GR a6GN0e0NtppChePdcAz1FTS+FN8Kpxoiykk+J8fC5tenjbu9kSqpHLu9jBrhUuhNwVGbpyZrzrl0 HPVD8SXj5EOOD/eDC64VjvYBZLuUbIVAfBN1t/C/SU+cAGtdGo+fVnzycUX5wmn6eCKPmWYJG2E/ ppTsuRCbvUD9fwquksG5GqLVKhzDQ3GrEyLKSXhsiK3T5j9EyxffCFOYi2wUlPyFFDQAhehESDjQ GoX0ho0oj8RPou6TxHJdcT0NTcWkO0AnG7+uXsnHqcas/72wvWF+mSf7N/Watp9kTXoluzeS0fB9 9CcZ/hvhSZTfh99pispZOXL9KrGrARkNUMu9ITbScZWs7xOYNt9pwxSZtYDsX/GE3xTkrXgwAsXm fud08FiTeC+m2/o7ppo+PTS/NBK5ARpDG5YHr++DpmVfreYdiX8mnp+DzPEG9WbqJON0JBenZofs sxBA1gj5NXGvfJu/Qh7HwQh/VDUEyUxCit5hH94QfKkEdu+GwK8BX0hvCF+D67xhjmXQCXMwJCZ+ olK0A1EKRCE4snsh42w8Mv/Zhxw9iD7Cjo7CyQC/KyF6oBfShL4PYgG+CHsYKyZxvxZSZBAgjhIz YDz+AbfD37GtbaoSKzgGt+lKfI/GZtay6vG4VXTpPsh+IcQhOk9I7WYeP5AM3HZ9+DaSGIp9HIuu huC4pCGGx+YD2fcc5tfIAA0h/Et4/jX8zz4fWAasIf4UbR9Y6HO4d8jAnd4U0Y8ageuCB+c+H5R3 CHU2mTMwZ+B/y8DfSMBLLOYXVuEAAAAASUVORK5CYII= ------=_Part_736_42316034.1453068563837-- ------=_Part_735_40563649.1453068563837--