This is a discussion on preferred way to use PG_GETARG_BYTEA_P in SPI within the Pgsql General forums, part of the PostgreSQL category; --> I'm curious what's considered the best way to invoke PG_GETARG_BYTEA_P in an SPI routine and properly check for null ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| I'm curious what's considered the best way to invoke PG_GETARG_BYTEA_P in an SPI routine and properly check for null input in non 'strict' routines. Right now, I'm looking at PG_GETARG_POINTER to check for null value before using PG_GETARG_BYTEA_P to assign to the bytea pointer. ISTM a little but unintuitive to have PG_GETARG_BYTEA_P crash on null input...why not just assign null and skip the de-toast call in the macro? merlin ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/ |
| |||
| "Merlin Moncure" <mmoncure@gmail.com> writes: > I'm curious what's considered the best way to invoke PG_GETARG_BYTEA_P > in an SPI routine and properly check for null input in non 'strict' > routines. Right now, I'm looking at PG_GETARG_POINTER to check for > null value before using PG_GETARG_BYTEA_P to assign to the bytea > pointer. That would be entirely wrong. In a non-strict function, test PG_ARGISNULL(n) before attempting any variant of PG_GETARG(n). Grepping for PG_ARGISNULL will yield lots of examples. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq |
| |||
| On 10/10/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Merlin Moncure" <mmoncure@gmail.com> writes: > > I'm curious what's considered the best way to invoke PG_GETARG_BYTEA_P > > in an SPI routine and properly check for null input in non 'strict' > > routines. Right now, I'm looking at PG_GETARG_POINTER to check for > > null value before using PG_GETARG_BYTEA_P to assign to the bytea > > pointer. > > That would be entirely wrong. In a non-strict function, test > PG_ARGISNULL(n) before attempting any variant of PG_GETARG(n). > Grepping for PG_ARGISNULL will yield lots of examples. well, there aren't all that many examples in contrib, and some of the ones that are there look like this (edited) from tsearch2: Datum rewrite_accum(PG_FUNCTION_ARGS) { QUERYTYPE *acc = (QUERYTYPE *) PG_GETARG_POINTER(0); ArrayType *qa = (ArrayType *) DatumGetPointer(PG_DETOAST_DATUM_COPY(PG_GETARG_DA TUM(1))); if (acc == NULL || PG_ARGISNULL(0)) { ....I since found the place in the documentation which explains this though, at the end of the portion describing the V1 calling convention. merlin ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| ||||
| "Merlin Moncure" <mmoncure@gmail.com> writes: > well, there aren't all that many examples in contrib, and some of the > ones that are there look like this (edited) from tsearch2: > Datum > rewrite_accum(PG_FUNCTION_ARGS) > { > QUERYTYPE *acc = (QUERYTYPE *) PG_GETARG_POINTER(0); > ArrayType *qa = (ArrayType *) > DatumGetPointer(PG_DETOAST_DATUM_COPY(PG_GETARG_DA TUM(1))); > if (acc == NULL || PG_ARGISNULL(0)) > { That might be safe but it sure looks like bad practice to me. In particular I think it's unwise to assume that the Datum value for a null will always be zero. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| Thread Tools | |
| Display Modes | |
|
|