Proposal: new large object API

Here is the proposed patches. If there's no objection, I will
commit(or Shall I wait for next "commit festa"?).

Note that I decide to use lo_import_with_oid, but the signature is
changed(the second and the third arguments are swapped because it
seems more natural).
--
Tatsuo Ishii
SRA OSS, Inc. Japan

I have posted proposed patches to pgsql-patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@postgresql.org> writes:

Here is the proposed patches. If there's no objection, I will
commit(or Shall I wait for next "commit festa"?).

No need to wait IMHO.

regards, tom lane

lo_import_with_oid added.

Note that actually committed function signature is:

Oid lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId);
--
Tatsuo Ishii
SRA OSS, Inc. Japan

lo_import_with_oid added.

Note that actually committed function signature is:

Oid lo_import_with_oid(PGconn *conn, const char *filename, Oid lobjId);
--
Tatsuo Ishii
SRA OSS, Inc. Japan

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?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@postgresql.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.

regards, tom lane

Tatsuo Ishii <ishii@postgresql.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

Tatsuo Ishii <ishii@postgresql.org> writes:

Breaking the type_sanity test is not acceptable. Put in a second C
function.

Are you talking opr_sanity?

Sorry, yes, too little caffeine ...

What is evil with a polymorphic function?

(1) It's creating a false match --- your proposed entry in the opr_sanity
results has nothing at all to do with what the test is looking for.

(2) Refactoring to have two separate C functions will make the code
clearer, and not noticeably longer.

regards, tom lane

What is evil with a polymorphic function?

(1) It's creating a false match --- your proposed entry in the opr_sanity
results has nothing at all to do with what the test is looking for.

(2) Refactoring to have two separate C functions will make the code
clearer, and not noticeably longer.

Ok, here is the revised patch.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

Tatsuo Ishii <ishii@postgresql.org> writes:

Ok, here is the revised patch.

This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.

SELECT lo_unlink(173454); -- deletes large object with OID 173454

  INSERT INTO image (name, raster)
      VALUES ('beautiful image', lo_import('/etc/motd'));
+ 
+ INSERT INTO image (name, raster)  -- same as above, but specify OID to use
+     VALUES ('beautiful image', lo_import('/etc/motd', 68583));

SELECT lo_export(image.raster, '/tmp/motd') FROM image
WHERE name = 'beautiful image';
</programlisting>

regards, tom lane

Tatsuo Ishii <ishii@postgresql.org> writes:

Ok, here is the revised patch.

This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.

SELECT lo_unlink(173454); -- deletes large object with OID 173454

INSERT INTO image (name, raster)
VALUES ('beautiful image', lo_import('/etc/motd'));
+ 
+ INSERT INTO image (name, raster)  -- same as above, but specify OID to use
+     VALUES ('beautiful image', lo_import('/etc/motd', 68583));

SELECT lo_export(image.raster, '/tmp/motd') FROM image
WHERE name = 'beautiful image';
</programlisting>

Thanks for the comment. I have committed with your suggested doc
changing.
--
Tatsuo Ishii
SRA OSS, Inc. Japan