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

From Takahiro Itagaki
Subject Re: Largeobject Access Controls (r2460)
Date
Msg-id 20100202093341.9A60.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: Largeobject Access Controls (r2460)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: Largeobject Access Controls (r2460)
List pgsql-hackers
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.


> 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).

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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Make TOAST_TUPLES_PER_PAGE configurable per table.
Next
From: Takahiro Itagaki
Date:
Subject: Re: New VACUUM FULL crashes on temp relations