2013/9/30 Heikki Linnakangas <hlinnakan...@vmware.com> > On 12.08.2013 21:08, Pavel Stehule wrote: > >> 2013/8/10 Tom Lane<t...@sss.pgh.pa.us>: >> >>> Pavel Stehule<pavel.stehule@gmail.**com <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<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. > > > c) probably there is a bug - it doesn't expect handling errors >> >> postgres=# select fbuilder.attachment_to_xml(0); >> WARNING: Snapshot reference leak: Snapshot 0x978f6f0 still referenced >> attachment_to_xml >> ─────────────────── >> [null] >> (1 row) >> > > Yeah, that's a server-side bug. inv_open() registers the snapshot before > checking if the large object exists. If it doesn't, the already-registered > snapshot is not unregistered, hence the warning. > > I've committed the attached fix for that bug. >
nice, I afraid so it is mine bug thank you Pavel > > - Heikki >
