Bruce Momjian さんは書きました:
KaiGai Kohei wrote:
Takahiro Itagaki wrote:
KaiGai Kohei <kai...@ak.jp.nec.com> wrote:
Tom Lane wrote:
Takahiro Itagaki <itagaki.takah...@oss.ntt.co.jp> writes:
<structname>pg_largeobject</structname> should not be readable by the
public, since the catalog contains data in large objects of all users.
This is going to be a problem, because it will break applications that
expect to be able to read pg_largeobject. Like, say, pg_dump.
Is it a right behavior, even if we have permission checks on large objects?
Can we use column-level access control here?
REVOKE ALL ON pg_largeobject FROM PUBLIC;
=> GRANT SELECT (loid) ON pg_largeobject TO PUBLIC;
Indeed, it seems to me reasonable.
We use "SELECT loid FROM pg_largeobject LIMIT 1" in pg_dump. We could
replace pg_largeobject_metadata instead if we try to fix only pg_dump,
but it's no wonder that any other user applications use such queries.
I think to allow reading loid is a balanced solution.
Right, I also remind this query has to be fixed up by other reason right now.
If all the large objects are empty, this query can return nothing, even if
large object entries are in pg_largeobject_metadata.
"metadata" seems very vague. Can't we come up with a more descriptive
name?
What about "property"?
The "metadata" was the suggested name from Robert Haas at the last
commit fest, because we may store any other properties of a large
object in this catalog future.
Also, how will this affect pg_migrator? pg_migrator copies
pg_largeobject and its index from the old to the new server. Is the
format inside pg_largeobject changed by this patch?
The format of pg_largeobject was not touched.
What happens when
there is no entry in pg_largeobject_metadata for a specific row?
In this case, these rows become orphan.
So, I think we need to create an empty large object with same LOID on
pg_migrator. It makes an entry on pg_largeobject_metadata without
writing anything to the pg_largeobject.
I guess rest of migrations are not difference. Correct?
Thanks,
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
