Tom Lane wrote: > KaiGai Kohei <kai...@ak.jp.nec.com> writes: >> The attached patch provides access control features on largeobject. >> This patch adds the ownership and two permissions (SELECT and UPDATE) on >> largeobjects. The two permissions controls reader and writer accesses to >> the largeobejcts. > > What about DELETE permissions? Should we track that separately from > UPDATE?
PostgreSQL checks ownership of the database object when user tries to drop it. This patch also add pg_largeobject_ownercheck() on lo_unlink(). >> The CREATE USER/ROLE statement got a new option: LARGEOBJECT/NOLARGEOBJECT. >> It enables to controls whether the user can create a largeobject, or not. > > I don't think this is necessary or appropriate. What should control privilege to create a new largeobject? Or, it implicitly allows everyone to create a new one? >> The pg_largeobject system catalog is reworked to manage its metadata. >> Actual data chunks are stored in the toast relation of pg_largeobject, > > This seems like a very confusing design, and one that (a) breaks > existing code to no purpose, (b) will greatly complicate in-place > upgrade. Instead of abusing a toast relation to do something > nonstandard, keep pg_largeobject as it is now and add a new, separate > catalog that carries ownership and permissions info for each LO OID. It was the original design just before the first commit fest. :-) I don't have any reason to oppose to it. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
