Re: Largeobject Access Controls (r2460) - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: Largeobject Access Controls (r2460)
Date
Msg-id 4B67861D.10002@ak.jp.nec.com
Whole thread Raw
In response to Re: Largeobject Access Controls (r2460)  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: Largeobject Access Controls (r2460)
List 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 by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Next
From: M Z
Date:
Subject: Re: contrib\xml2 package's xpath_table function in PostgreSQL