Thread: Exception Handling in C-Language Functions?
I have the created a C-Language function (code is below). Now, I
wonder: How do I handle exceptions, for example if malloc cannot assign
the necessary memory? Do "palloc" and "pfree" handle such a case
cleanly? Should I simply use an "assert"?
#include "postgres.h"
#include <string.h>
#include <stdlib.h>
#include "fmgr.h"
#include "libinn.h"
PG_FUNCTION_INFO_V1(ffiinews_uwildmat);
/* Wrapper for INN's function uwildmat. Needs parameters in UTF-8. */
Datum ffiinews_uwildmat(PG_FUNCTION_ARGS) {
VarChar *text = PG_GETARG_VARCHAR_P(0);
VarChar *pattern = PG_GETARG_VARCHAR_P(1);
int text_len = VARSIZE(text)-VARHDRSZ;
int pattern_len = VARSIZE(pattern)-VARHDRSZ;
char *tmp_text = (char *)malloc(text_len+1);
if (tmp_text == NULL)
; /* What now? */
char *tmp_pattern = (char *)malloc(pattern_len+1);
if (tmp_pattern == NULL)
; /* What now? */
strncpy(tmp_text, VARDATA(text), text_len);
tmp_text[text_len] = '\0';
strncpy(tmp_pattern, VARDATA(pattern), pattern_len);
tmp_pattern[pattern_len] = '\0';
bool matches = uwildmat(tmp_text, tmp_pattern);
free(tmp_pattern);
free(tmp_text);
PG_RETURN_BOOL(matches);
}
--
Felix E. Klee
Felix E. Klee wrote: > I have the created a C-Language function (code is below). Now, I > wonder: How do I handle exceptions, for example if malloc cannot assign > the necessary memory? Do "palloc" and "pfree" handle such a case > cleanly? Yes -- they will roll back the current transaction on if there is no memory available. You can catch the error via PG_TRY() in 8.0, although in the case of OOM there isn't probably a lot your exception handler could do... -Neil
At Sat, 21 May 2005 20:13:13 +1000, Neil Conway wrote: > > Do "palloc" and "pfree" handle such a case cleanly? > > Yes -- they will roll back the current transaction on if there is no > memory available. Great. So I just use those. > You can catch the error via PG_TRY() in 8.0 [...] Nice, but we're not deploying 8.0. However, at the moment, out of memory exceptions seem to be the only ones that I've to deal with. -- Felix E. Klee
"Felix E. Klee" <felix.klee@inka.de> writes:
> I have the created a C-Language function (code is below). Now, I
> wonder: How do I handle exceptions, for example if malloc cannot assign
> the necessary memory? Do "palloc" and "pfree" handle such a case
> cleanly? Should I simply use an "assert"?
As a general rule, never ever use malloc in backend code --- there's way
too much risk of causing a memory leak. (If your function for some
reason errors out before reaching the free(), that memory is gone.
Lather, rinse, repeat a few million times, as is not unlikely to happen
in a database server, and you've got a big problem.)
Use palloc instead. You don't have to check it for a failure return,
as Neil already noted, and you can be sloppy about remembering to free
the result ... in fact, there's no real reason to free it at all, since
anything palloc gives you inside a function will be short-term memory.
See src/backend/utils/mmgr/README for details.
If you want to report your own errors, use elog/ereport.
BTW, a more future-proof way of doing what you want:
> VarChar *text = PG_GETARG_VARCHAR_P(0);
> int text_len = VARSIZE(text)-VARHDRSZ;
> char *tmp_text = (char *)malloc(text_len+1);
> if (tmp_text == NULL)
> ; /* What now? */
> strncpy(tmp_text, VARDATA(text), text_len);
> tmp_text[text_len] = '\0';
is to let the varchar output routine do it:
Datum text_datum = PG_GETARG_DATUM(0);
char *text;
text = DatumGetCString(DirectFunctionCall1(varcharout, text_datum));
This avoids assuming that you know the internal representation of
varchar (and if you think that's frozen for eternity, you haven't
been reading the discussions of ramping up our locale support...)
regards, tom lane
At Sat, 21 May 2005 10:30:47 -0400, Tom Lane wrote: > BTW, a more future-proof way of doing what you want: > > > [...] > > is to let the varchar output routine do it: > > Datum text_datum = PG_GETARG_DATUM(0); > char *text; > > text = DatumGetCString(DirectFunctionCall1(varcharout, text_datum)); > > This avoids assuming that you know the internal representation of > varchar (and if you think that's frozen for eternity, you haven't been > reading the discussions of ramping up our locale support...) Thanks for all those hints! I've now adapted my code as you recommended and it works fine, although I'm not certain what DirectFunctionCall1 and DatumGetCString actually do (it seems that the only documentation of these functions is in the source code, and I'm too lazy to sift through it at the moment). -- Felix E. Klee
Tom Lane wrote: > "Felix E. Klee" <felix.klee@inka.de> writes: > > BTW, a more future-proof way of doing what you want: > > >> VarChar *text = PG_GETARG_VARCHAR_P(0); >> int text_len = VARSIZE(text)-VARHDRSZ; >> char *tmp_text = (char *)malloc(text_len+1); >> if (tmp_text == NULL) >> ; /* What now? */ >> strncpy(tmp_text, VARDATA(text), text_len); >> tmp_text[text_len] = '\0'; > > > is to let the varchar output routine do it: > > Datum text_datum = PG_GETARG_DATUM(0); > char *text; > > text = DatumGetCString(DirectFunctionCall1(varcharout, text_datum)); > > This avoids assuming that you know the internal representation of > varchar (and if you think that's frozen for eternity, you haven't > been reading the discussions of ramping up our locale support...) This form of dealing with arguments is interesting to learn about. Is there any documentation of this stuff or do I need to dive into the source? -greg
greg landrum <greg.landrum@gmail.com> writes:
> Tom Lane wrote:
>> text = DatumGetCString(DirectFunctionCall1(varcharout, text_datum));
> This form of dealing with arguments is interesting to learn about. Is
> there any documentation of this stuff or do I need to dive into the source?
The original motivation for this notation is discussed in
src/backend/utils/fmgr/README, and there's some basic docs in the
main SGML documentation. Beyond that, looking at code that does
something close to what you want has always been the best guide ...
regards, tom lane