Re: Largeobject Access Controls (r2460)

Kohei KaiGai <kaigai@kaigai.gr.jp>

From: KaiGai Kohei <kaigai@kaigai.gr.jp>
To: Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>, pgsql-hackers@postgresql.org
Date: 2009-12-12T04:04:55Z
Lists: pgsql-hackers
Takahiro Itagaki wrote:
> KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:
> 
>>>>   We have to reference pg_largeobject_metadata to check whether a certain
>>>>   large objct exists, or not.
>> It is a case when we create a new large object, but write nothing.
> 
> OK, that makes sense.
> 
> In addition of the patch, we also need to fix pg_restore with
> --clean option. I added DropBlobIfExists() in pg_backup_db.c.
> 
> A revised patch attached. Please check further mistakes.

+ void
+ DropBlobIfExists(ArchiveHandle *AH, Oid oid)
+ {
+   const char *lo_relname;
+   const char *lo_colname;
+
+   if (PQserverVersion(AH->connection) >= 80500)
+   {
+       lo_relname = "pg_largeobject_metadata";
+       lo_colname = "oid";
+   }
+   else
+   {
+       lo_relname = "pg_largeobject";
+       lo_colname = "loid";
+   }
+
+   /* Call lo_unlink only if exists to avoid not-found error. */
+   ahprintf(AH, "SELECT CASE WHEN EXISTS(SELECT 1 FROM pg_catalog.%s WHERE %s = '%u') THEN pg_catalog.lo_unlink('%u') END;\n",
+            lo_relname, lo_colname, oid, oid);
+ }

I think the following approach is more reasonable for the current design.

   if (PQserverVersion(AH->connection) >= 80500)
   {
       /* newer query */
       ahprintf(AH, "SELECT pg_catalog.lo_unlink(oid) "
                    "FROM pg_catalog.pg_largeobject_metadata "
                    "WHERE oid = %u;\n", oid);
   }
   else
   {
       /* original query */
       ahprintf(AH, "SELECT CASE WHEN EXISTS(SELECT 1 FROM pg_catalog.pg_largeobject WHERE loid = '%u') "
                    "THEN pg_catalog.lo_unlink('%u') END;\n", oid, oid);
   }

We don't have any reason why still CASE ... WHEN and subquery for the given
LOID. Right?

The fix-lo-contrib.patch looks good for me.

> BTW, we can optimize lo_truncate because we allow metadata-only large
> objects. inv_truncate() doesn't have to update the first data tuple to
> be zero length. It only has to delete all corresponding tuples like as:
>     DELETE FROM pg_largeobject WHERE loid = {obj_desc->id}

Right, when inv_truncate takes an aligned length by LOBLKSIZE.

I'll also submit a small patch on CF-Jan, OK?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>