Re: [HACKERS] [BUG?] strange PQgetisnull
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] [BUG?] strange PQgetisnull |
Дата | |
Msg-id | 1925.900598283@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [BUG?] strange PQgetisnull ("Park, Chul-Su" <pcs@mhlx01.kek.jp>) |
Список | pgsql-hackers |
"Park, Chul-Su" <pcs@mhlx01.kek.jp> writes: > I got strange result with PQgetisnull, say > for empty table(I think that it's empty so null) > I guess that > after fetch some selection > PQgetisnull(result, 0, 0) should give me "1 or true" > But > it gives me > ERROR! field 0(of 0) of row 0(of 0) is not available... Segmentation > Fault PQgetisnull is buggy in 6.3.2: it range-checks the tuple and field numbers, and complains if they are out of range ... but then falls through and tries to reference the tuple info anyway. Thus, segfault. It should return a default value (probably 1 to pretend the field is NULL) when the indexes are out of range. This is already fixed in the current development sources, but if you want to stick with a 6.3.2 server then you will have to modify fe-exec.c yourself. > so I tried > if (PQntuples(result) == 0) > ... > But PQntules gives me "1" not "0" ! The PQgetisnull error message you quoted above indicates (after looking at the 6.3.2 sources) that nfields was 1 and ntuples was 0. I think you are testing the results of a different query here. > do I have to check result with > char* value = PQgetvalue(result, 0, 0); > and test value is "" or not? any idea??? No, you should be checking PQntuples and perhaps also PQnfields to be sure that the indexes you are going to use are OK. regards, tom lane
В списке pgsql-hackers по дате отправления: