Ok, it seems that another change to the PostgreSQL large object APIs
happened in PG 9.0: large objects got ACLs. Before that, anybody could
access them. In PL/Java, anybody still can. :(

The ideal accommodation on PL/Java's side will be to retarget PL/Java's
LargeObject code from the PG inv_api.c layer to the be-fsstubs.c layer
(if something doesn't make that prohibitively difficult), because that's
where the 9.0+ access checks happen. Otherwise, the checking code needs
to be duplicated in PL/Java.

The fsstubs layer has only-good-within-one-transaction semantics.
Happily, that's all that's expected for the JDBC *LOB interfaces,
which presumably are the public API this stuff should ultimately have.

Too involved for 1.5.0. However, this is a good argument for a least-
privilege, no-public-by-default installation of the 'java' language,
documenting how GRANT USAGE can then be used to allow specific
users/roles to make PL/Java functions.

Moral: this wasn't a problem before 9.0, when everybody knew LOBs had
no access controls. It became a problem when PG added access controls
for them, and PL/Java didn't follow suit. What's a trusted language
today could need adjustments tomorrow, so no-public-usage-by-default
really seems like the best posture; the user/installer should always be
encouraged to follow the least privilege principle.