Re: Largeobject Access Controls (r2460)

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: Largeobject Access Controls (r2460)
Дата
Msg-id 4B60F987.2050406@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: Largeobject Access Controls (r2460)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Ответы Re: Largeobject Access Controls (r2460)  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Re: Largeobject Access Controls (r2460)  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Список pgsql-hackers
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@ak.jp.nec.com>

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: make everything target