Re: Proposal: new large object API

> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> > It seems I forgot about the serer side lo_import. Included are the
> > patches to add new form of lo_import which accepts the large object id
> > as the second argument.
>
> > Comments, objection?
>
> Breaking the type_sanity test is not acceptable. Put in a second C
> function.

Are you talking opr_sanity?

From what I read from opr_sanity.sql:

-- Look for uses of different type OIDs in the argument/result type fields
-- for different aliases of the same built-in function.
-- This indicates that the types are being presumed to be binary-equivalent,
-- or that the built-in function is prepared to deal with different types.
-- That's not wrong, necessarily, but we make lists of all the types being
-- so treated. Note that the expected output of this part of the test will
-- need to be modified whenever new pairs of types are made binary-equivalent,
-- or when new polymorphic built-in functions are added!
-- Note: ignore aggregate functions here, since they all point to the same
-- dummy built-in function.

What is evil with a polymorphic function?
--
Tatsuo Ishii
SRA OSS, Inc. Japan