Re: Largeobject Access Controls (r2460)

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: Largeobject Access Controls (r2460)
Дата
Msg-id 4B67861D.10002@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: Largeobject Access Controls (r2460)  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Ответы Re: Largeobject Access Controls (r2460)
Список pgsql-hackers
(2010/02/02 9:33), Takahiro Itagaki wrote:
> 
> KaiGai Kohei<kaigai@ak.jp.nec.com>  wrote:
> 
>>> Can we remove such path and raise an error instead?
>>> Also, even if we support the older servers in the routine,
>>> the new bytea format will be another problem anyway.
>>
>> OK, I'll fix it.
> 
> I think we might need to discuss about explicit version checks in pg_restore.
> It is not related with large objects, but with pg_restore's capability.
> We've not supported to restore a dump to older servers, but we don't have any
> version checks, right? Should we do the checks at the beginning of restoring?
> If we do so, LO patch could be more simplified.

I agree it is a good idea.

>> The --schema-only with large objects might be unnatural, but the
>> --data-only with properties of large objects are also unnatural.
>> Which behavior is more unnatural?
> 
> I think large object metadata is a kind of row-based access controls.
> How do we dump and restore ACLs per rows when we support them for
> normal tables? We should treat LO metadata as same as row-based ACLs.
> In my opinion, I'd like to treat them as part of data (not of schema).

OK, I'll update the patch according to the behavior you suggested.
| I'd prefer to keep the existing behavior:
|   * default or data-only : dump all attributes and data of blobs
|   * schema-only          : don't dump any blobs
| and have independent options to control blob dumps:
|   * -b, --blobs    : dump all blobs even if schema-only
|   * -B, --no-blobs : [NEW] don't dump any blobs even if default or data-only

Please wait for a while. 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
Следующее
От: M Z
Дата:
Сообщение: Re: contrib\xml2 package's xpath_table function in PostgreSQL