2013/10/21 Noah Misch <n...@leadboat.com> > On Mon, Sep 30, 2013 at 01:06:15PM +0300, Heikki Linnakangas wrote: > > On 12.08.2013 21:08, Pavel Stehule wrote: > >> 2013/8/10 Tom Lane<t...@sss.pgh.pa.us>: > >>> Pavel Stehule<pavel.steh...@gmail.com> writes: > >>>> I found so there are no simple API for working with LO from PL without > >>>> access to file system. > >>> > >>> What? See lo_open(), loread(), lowrite(), etc. > >> > >> yes, so there are three problems with these functions: > >> > >> a) probably (I didn't find) undocumented > > > > It's there, although it's a bit difficult to find by searching. See: > > http://www.postgresql.org/docs/devel/static/lo-funcs.html. > > > > I don't actually agree with this phrase on that page: > > > >> The ones that are actually useful to call via SQL commands are > >> lo_creat, lo_create, lo_unlink, lo_import, and lo_export > > > > Calling lo_open, loread and lowrite seems equally useful to me. > > > >> b) design with lo handler is little bit PL/pgSQL unfriendly. > > > > It's a bit awkward, I agree. > > All the other large object functions are named like lo*, so I think new > ones > should also be lo* rather than *_lo. One of the key benefits of large > objects, compared to a bytea column in some table, is their efficiency when > reading or writing only a subset of the object. However, the proposed > functions only deal with the large object as a whole. We could easily fix > that. Consider this list of new functions in their place: > > lo_create(oid, bytea) RETURNS oid -- new LO with content (similar to > make_lo) > lo_get(oid) RETURNS bytea -- read entire LO (same > as load_lo) > lo_get(oid, bigint, int) RETURNS bytea -- read from offset for length > lo_put(oid, bigint, bytea) RETURNS void -- write data at offset > > Anything we do here effectively provides wrappers around the existing > functions tailored toward the needs of libpq. A key outstanding question > is > whether doing so provides a compelling increment in usability. On the plus > side, adding such functions resolves the weirdness of having a variety of > database object that is easy to access from libpq but awkward to access > from > plain SQL. On the minus side, this could easily live as an extension > module. > I have not used the large object facility to any significant degree, but I > generally feel this is helpful enough to justify core inclusion. Any other > opinions on the general suitability or on the specifics of the API offered? >
fast reply - I reply again later in my office. I don't think so new functions (for bytea type) has any sense in libpq. >From C is usually better to use a native C interface than ensure conversion to bytea. Probably the interface libpq should be modernized, but it complete and enough now. I don't have a motivation to enhance a API now. And a fact, so proposed bytea functions are not in libpq is a reason why I used different naming convention. A main motivation was a access from PL to LO without obscure patterns - mainly for PL/pgSQL. For other languages it is available - but maybe better direction is direct mapping to related primitives based on host environment possibilities. Today evening I'll look on your proposal with some more time. Regards Pavel > > Thanks, > nm > > -- > Noah Misch > EnterpriseDB http://www.enterprisedb.com >
