Large Object be-fsstubs.c RFE

Because it's not obvious which of the many postgres newsgroups would be
appropriate, I'm posting a request for enhancement to be-fsstubs.c
here. Specifically, if a large object descriptor is re-used without an
explicit transaction, the lo_* () routines in be-fsstubs.c issue this
error message:

lo_*: invalid large obj descriptor (<d>)

even though the failure may be due to the previous release of large
object descriptor pool (viz., cookies_size is actually 0). Thus, I
suggest the following changes to be-fsstubs.c to explicitly diagnose
this condition:

115,134d114
<
< #undef _CHECK_LO_DESC
< #define _CHECK_LO_DESC(_name, _retCode)
\
< {
\
< if (cookies_size == 0)
\
< {
\
< elog (ERROR,
\
< #_name
\
< ": missing BEGIN transaction, large object descriptor
(%d)",\
< fd);
\
<
_retCode;
\
< }
\
< else if (fd < 0 || fd >= cookies_size || cookies[fd] ==
NULL) \
< {
\
< elog (ERROR, #_name ": invalid large obj descriptor (%d)", fd);
\
<
_retCode;
\
< }
\
< }
<
<
141c121,125
< _CHECK_LO_DESC (lo_close, PG_RETURN_INT32 (-1));
---

if (fd < 0 || fd >= cookies_size || cookies[fd] == NULL)
{
elog(ERROR, "lo_close: invalid large obj descriptor

(%d)", fd);

PG_RETURN_INT32(-1);
}

173c157,161
< _CHECK_LO_DESC (lo_read, return -1);
---

if (fd < 0 || fd >= cookies_size || cookies[fd] == NULL)
{
elog(ERROR, "lo_read: invalid large obj descriptor

(%d)", fd);

return -1;
}

191c179,183
< _CHECK_LO_DESC (lo_write, return -1);
---

if (fd < 0 || fd >= cookies_size || cookies[fd] == NULL)
{
elog(ERROR, "lo_write: invalid large obj descriptor

(%d)", fd);

return -1;
}

213c205,209
< _CHECK_LO_DESC (lo_lseek, PG_RETURN_INT32 (-1));
---

if (fd < 0 || fd >= cookies_size || cookies[fd] == NULL)
{
elog(ERROR, "lo_lseek: invalid large obj descriptor

(%d)", fd);

PG_RETURN_INT32(-1);
}

264c260,264
< _CHECK_LO_DESC (lo_tell, PG_RETURN_INT32 (-1));
---

if (fd < 0 || fd >= cookies_size || cookies[fd] == NULL)
{
elog(ERROR, "lo_tell: invalid large object descriptor

(%d)", fd);

PG_RETURN_INT32(-1);
}

Thanks!

...Martin Fong mwfong@sri.com