Re: Largeobject Access Controls (r2460)

KaiGai Kohei <kaigai@ak.jp.nec.com> wrote:

> > I don't think this is necessarily a good idea.  We might decide to treat
> > both things separately in the future and it having them represented
> > separately in the dump would prove useful.
> 
> I agree. From design perspective, the single section approach is more
> simple than dual section, but its change set is larger than the dual.

OK.


When I tested a custom dump with pg_restore, --clean & --single-transaction
will fail with the new dump format because it always call lo_unlink()
even if the large object doesn't exist. It comes from dumpBlobItem:

! dumpBlobItem(Archive *AH, BlobInfo *binfo)
!     appendPQExpBuffer(dquery, "SELECT lo_unlink(%s);\n", binfo->dobj.name);

The query in DropBlobIfExists() could avoid errors -- should we use it here?
| SELECT lo_unlink(oid) FROM pg_largeobject_metadata WHERE oid = %s;


BTW, --clean option is ambiguous if combined with --data-only. Restoring
large objects fails for the above reason if previous objects don't exist,
but table data are restored *without* truncation of existing data. Will
normal users expect TRUNCATE-before-load for --clean & --data-only cases?
   Present behaviors are;       Table data    - Appended. (--clean is ignored)       Large objects - End with an error
ifobject doesn't exist.   IMO, ideal behaviors are:       Table data    - Truncate existing data and load new ones.
 Large objects - Work like as MERGE (or REPLACE, UPSERT).
 

Comments?

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center