The attached patch uses one TOC entry for each blob objects.

It adds two new section types.

* "BLOB ITEM"

This section provides properties of a certain large object.
It contains a query to create an empty large object, and restore
ownership of the large object, if necessary.

|  --
|  -- Name: 16406; Type: BLOB ITEM; Schema: -; Owner: ymj
|  --
|
|  SELECT lo_create(16406);
|
|  ALTER LARGE OBJECT "16406" OWNER TO ymj;

The comment descriptions were moved to COMMENT section, like any other
object classes.

| --
| -- Name: LARGE OBJECT 16406; Type: COMMENT; Schema: -; Owner: ymj
| --
|
| COMMENT ON LARGE OBJECT 16406 IS 'This is a small large object.';

Also, access privileges were moved to ACL section.

| --
| -- Name: 16405; Type: ACL; Schema: -; Owner: kaigai
| --
|
| REVOKE ALL ON LARGE OBJECT 16405 FROM PUBLIC;
| REVOKE ALL ON LARGE OBJECT 16405 FROM kaigai;
| GRANT ALL ON LARGE OBJECT 16405 TO kaigai;
| GRANT ALL ON LARGE OBJECT 16405 TO PUBLIC;


* "BLOB DATA"

This section is same as existing "BLOBS" section, except for _LoadBlobs()
does not create a new large object before opening it with INV_WRITE, and
lo_truncate() will be used instead of lo_unlink() when --clean is given.

The legacy sections ("BLOBS" and "BLOB COMMENTS") are available to read
for compatibility, but newer pg_dump never create these sections.


Internally, the getBlobs() scans all the blobs and makes DO_BLOB_ITEM
entries for each blobs and a DO_BLOB_DATA entry if the database contains
a large object at least.

The _PrintTocData() handles both of "BLOBS" and "BLOB DATA" sections.
If the given section is "BLOB DATA", it calls _LoadBlobs() of the specified
format with compat = false, because this section is new style.

In this case, _LoadBlobs() does not create a large object before opening
it with INV_WRITE, because "BLOB ITEM" section already create an empty
large obejct.

And DropBlobIfExists() was renamed to CleanupBlobIfExists(), because it
is modified to apply lo_truncate() if "BLOB DATA" section.
When --clean is given, SELECT lo_unlink(xxx) will be injected on the head
of queries to store, instead of the mid-flow of loading blobs.

One remained issue is the way to decide whether blobs to be dumped, or not.
Right now, --schema-only eliminate all the blob dumps.
However, I think it should follow the manner in any other object classes.

 -a, --data-only    ... only "BLOB DATA" sections, not "BLOB ITEM"
 -s, --schema-only  ... only "BLOB ITEM" sections, not "BLOB DATA"
 -b, --blobs        ... both of "BLOB ITEM" and "BLOB DATA" independently
                        from --data-only and --schema-only?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

• Re: Largeobject Access Controls (r2460) at 2010-01-23 07:39:17 from KaiGai Kohei

Responses

• Re: Largeobject Access Controls (r2460) at 2010-01-28 09:21:43 from Takahiro Itagaki
• Re: Largeobject Access Controls (r2460) at 2010-02-01 05:19:16 from Takahiro Itagaki

pgsql-hackers by date

Next:	From: Andrew Dunstan	Date: 2010-01-28 02:44:55
	Subject: Re: make everything target
Previous:	From: KaiGai Kohei	Date: 2010-01-28 01:13:49
	Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns