Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aIt56-0007Y0-Bh for pgsql-sql@arkaria.postgresql.org; Tue, 12 Jan 2016 07:09:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aIt54-0003qc-MQ for pgsql-sql@arkaria.postgresql.org; Tue, 12 Jan 2016 07:09:26 +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.84) (envelope-from ) id 1aIt53-0003qV-T9 for pgsql-sql@postgresql.org; Tue, 12 Jan 2016 07:09:26 +0000 Received: from post.visena.com ([46.226.10.50]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aIt4w-00005P-01 for pgsql-sql@postgresql.org; Tue, 12 Jan 2016 07:09:24 +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=x+K9W/dfk23XNbpENbyRcCki5+f3iMQLiHrJkA5i7ac=; b=UVW2HTZWPrltt/XpABxtG1Q6KnUQzWbDNjBWSGBs6L/ClcxXZbLv0+okjmONo6m1lQ+vxSYoMJ4mwtpKvphtsnMKtOkE88KBqaIvbWRS++sKU9n+E1avV+c7v8ihbpf87OF5QPrh3LOSepi2jj9fpQDf5YVmgtEUzhILccaoX1c=; 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 1aIt4q-0006Yz-Kl for pgsql-sql@postgresql.org; Tue, 12 Jan 2016 08:09:14 +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 1aIt4q-0006qD-Jr for pgsql-sql@postgresql.org; Tue, 12 Jan 2016 08:09:12 +0100 Date: Tue, 12 Jan 2016 08:09:12 +0100 (CET) From: Andreas Joseph Krogh To: pgsql-sql@postgresql.org Message-ID: In-Reply-To: <653214003.3602816.1452562366970.JavaMail.yahoo@mail.yahoo.com> Subject: Re: BLOBs MIME-Version: 1.0 X-Mailer: Visena Mail 2.0.0-SNAPSHOT X-Spam-Score: -1.0 X-Spam-Report: SpamAssasin (score=-1.0, required 5.0 ALL_TRUSTED=-1, HTML_MESSAGE=0.001) X-Pg-Spam-Score: -2.0 (--) Content-Type: multipart/related; boundary="----=_Part_178_1110127509.1452582552532" 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_177_824660767.1452582552532 Content-Type: multipart/related; boundary="----=_Part_178_1110127509.1452582552532" ------=_Part_178_1110127509.1452582552532 Content-Type: multipart/alternative; boundary="----=_Part_179_2120321878.1452582552548" ------=_Part_179_2120321878.1452582552548 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 tirsdag 12. januar 2016 kl. 02:32:46, skrev Eugene Yin >: I did some search on the OID data type. =C2=A0Here is something I found reg= arding=20 to the deletion of the OID data. =C2=A0 QUOTE: =C2=A0 "The Large Object method for storing binary data is better suited to storin= g=20 very large values, but it has its own limitations. Specifically deleting a = row=20 that contains a Large Object reference does not delete the Large Object.=C2= =A0 =C2=A0 Deleting the Large Object is a separate operation that needs to be performe= d.=C2=A0 =C2=A0 Large Objects also have some security issues since anyone connected to the= =20 database can view and/or modify any Large Object, even if they don't have= =20 permissions to view/update the row containing the Large Object reference." =C2=A0 F rom:=C2=A0 https://jdbc.postgresql.org/documentation/84/binary-data.html=20 =C2=A0 =C2=A0 So I have two questions: =C2=A0 1) =C2=A0If it is true that "Deleting the Large Object is a separate operat= ion that=20 needs to be performed.", after the deletion, what operation I need to perfo= rm,=20 in order to delete the OID data in the table? =C2=A0Possiblely put into an = after=20 trigger =C2=A0 2) "Large Objects also have some security issues since anyone connected to = the=20 database can view and/or modify any Large Object". =C2=A0Will this pose a r= eal risk=20 to the security? =C2=A0or just a forethought? =C2=A0 1) You don't need to perform any "after delete"-operation as a developer. B= ut=20 the DBA (or someone else) has to execute vacuumlo (see "man vacuumlo" for m= ore=20 info) using cron or some other periodic scheduling tool. =C2=A0 2) Your mileage may vary, but for our app this isn't an issue. =C2=A0 PS: 8.4 is EOL, use a more current version, preferably 9.5. I also recommend the -ng driver as it's the only one with proper BLOB-suppo= rt,=20 as mentioned earlier in this thread. =C2=A0 -- Andreas Joseph Krogh CTO / Partner - Visena AS Mobile: +47 909 56 963 andreas@visena.com www.visena.com =C2=A0 ------=_Part_179_2120321878.1452582552548 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P=C3=A5 tirsdag 12. januar 2016 kl. 02:32:46, skrev Eugene Yin <eugeneymail@ymail.com>:
I did some search= on the OID data type. =C2=A0Here is something I found regarding to the del= etion of the OID data.
=C2=A0
QUOTE:
=C2=A0
"The Large O= bject method for storing binary data is better suited to storing very large= values, but it has its own limitations. Specifically deleting a row that c= ontains a Large Object reference does not delete the Large Object.=C2=A0
=C2=A0
Deleting the Larg= e Object is a separate operation that needs to be performed.=C2=A0
=C2=A0
Large Objects als= o have some security issues since anyone connected to the database can view= and/or modify any Large Object, even if they don't have permissions to vie= w/update the row containing the Large Object reference."
=C2=A0
=C2=A0
=C2=A0
So I have two que= stions:
=C2=A0
1) =C2=A0If it is= true that "Deleting the Large Object is a separate operation that nee= ds to be performed.", after the deletion, what operation I need to per= form, in order to delete the OID data in the table? =C2=A0Possiblely put in= to an after trigger
=C2=A0
2) "Large Ob= jects also have some security issues since anyone connected to the database= can view and/or modify any Large Object". =C2=A0Will this pose a real= risk to the security? =C2=A0or just a forethought?
=C2=A0
1) You don't need to perform any "after delete"-operation as= a developer. But the DBA (or someone else) has to execute vacuumlo (see &q= uot;man vacuumlo" for more info) using cron or some other periodic sch= eduling tool.
=C2=A0
2) Your mileage may vary, but for our app this isn't an issue.
=C2=A0
PS: 8.4 is EOL, use a more current version, preferably 9.5.
I also recommend the -ng driver as it's the only one with proper BLOB-= support, as mentioned earlier in this thread.
=C2=A0
--
Andrea= s Joseph Krogh
CTO / Partner<= /span> - Visena AS
Mobile: +47 90= 9 56 963
=3D""
=C2=A0
------=_Part_179_2120321878.1452582552548-- ------=_Part_178_1110127509.1452582552532 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_178_1110127509.1452582552532-- ------=_Part_177_824660767.1452582552532--