Re: [HACKERS] Proposal: new large object API

2008-03-21 Thread Tatsuo Ishii
> Tatsuo Ishii <[EMAIL PROTECTED]> 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(

Re: [HACKERS] Proposal: new large object API

2008-03-21 Thread Tom Lane
Tatsuo Ishii <[EMAIL PROTECTED]> 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); -- del

Re: [HACKERS] Proposal: new large object API

2008-03-21 Thread Tatsuo Ishii
> > 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 l

Re: [HACKERS] Proposal: new large object API

2008-03-20 Thread Tom Lane
Tatsuo Ishii <[EMAIL PROTECTED]> 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 t

Re: [HACKERS] Proposal: new large object API

2008-03-20 Thread Tatsuo Ishii
> 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.

Re: [HACKERS] Proposal: new large object API

2008-03-20 Thread Tom Lane
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

Re: [HACKERS] Proposal: new large object API

2008-03-19 Thread Tatsuo Ishii
> 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

Re: [HACKERS] Proposal: new large object API

2008-03-18 Thread Tatsuo Ishii
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 > I have posted proposed patches to pgsql-patches. > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > > > I would li

Re: [HACKERS] Proposal: new large object API

2008-03-17 Thread Tatsuo Ishii
I have posted proposed patches to pgsql-patches. -- Tatsuo Ishii SRA OSS, Inc. Japan > I would like to propose new large object client side API for 8.4. > > Currently we have: > > Oid lo_import(PGconn *conn, const char *filename); > > But we do not have an API which imports a large obje

[HACKERS] Proposal: new large object API

2008-03-13 Thread Tatsuo Ishii
I would like to propose new large object client side API for 8.4. Currently we have: Oid lo_import(PGconn *conn, const char *filename); But we do not have an API which imports a large object specifying the object id. This is inconvenient and inconsistent since we already have lo_create