Re: Re[2]: SPI_getvalue problem
От | Tom Lane |
---|---|
Тема | Re: Re[2]: SPI_getvalue problem |
Дата | |
Msg-id | 20475.980749986@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re[2]: SPI_getvalue problem (Alex Guryanow <gav@nlr.ru>) |
Ответы |
Re[4]: SPI_getvalue problem
|
Список | pgsql-general |
Alex Guryanow <gav@nlr.ru> writes: > You have right. One of the values passed to SPI_getvalue is NULL. This is second parameter > (tupdesc). But why on Linux it is not NULL, and on Solaris is? > Here is part of my trigger-code: > rel = CurrentTriggerData->tg_relation; > trigtuple = CurrentTriggerData->tg_trigtuple; > newtuple = CurrentTriggerData->tg_newtuple; > tupdesc = rel->rd_att; > elog(DEBUG, "before 1 SPI"); > elog(DEBUG, "triggered for relation %s", SPI_getrelname(CurrentTriggerData->tg_relation) ); > id = atoi( SPI_getvalue( trigtuple, tupdesc, 1 ) ); > elog( DEBUG, "before 1.5 SPI" ); // !!! this isn't called in Solaris Are you sure that rel->rd_att is null? That seems extremely improbable. What I think is more likely is that the first column of the tuple contains a SQL NULL, and consequently SPI_getvalue returns a NULL pointer. You are passing that NULL to atoi() without any check. I'm not sure what Linux' atoi() does on NULL input, but a coredump on Solaris is very believable ... regards, tom lane
В списке pgsql-general по дате отправления: