> Tatsuo Ishii <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
