Greg Smith wrote:
> I just looked over the latest version of this patch and it seems to
> satisfy all the issues suggested by the initial review. This looks like
> it's ready for a committer from a quality perspective and I'm going to
> mark it as such.
Thanks for your efforts.
> I have a guess what some of the first points of discussion are going to
> be though, so might as well raise them here. This patch is 2.8K lines
> of code that's in a lot of places: a mix of full new functions, tweaks
> to existing ones, docs, regression tests, it's a well structured but
> somewhat heavy bit of work. One obvious questions is whether there's
> enough demand for access controls on large objects to justify adding the
> complexity involved to do so.
At least, it is a todo item in the community: http://wiki.postgresql.org/wiki/Todo#Binary_Data
Apart from SELinux, it is quite natural to apply any access controls on
binary data. If we could not have any valid access controls, users will
not want to store their sensitive information, such as confidential PDF
files, as a large object.
> A second thing I'm concerned about is
> what implications this change would have for in-place upgrades. If
> there's demand and it's not going to cause upgrade issues, then we just
> need to find a committer willing to chew on it. I think those are the
> main hurdles left for this patch.
I guess we need to create an empty entry with a given OID into the
pg_largeobject_metadata for each large objects when we try to upgrade
in-place from 8.4.x or earlier release to the upcoming release.
However, no format changes in the pg_largeobject catalog, including
an empty large object, so I guess we need a small amount of additional
support in pg_dump to create empty metadata.
I want any suggestion about here.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
