On Wed, 11 Dec 2002, David Wheeler wrote: > > Because libpq is C based, and we pass the query as a C string to the > > backend, I can not think of a way to make nulls pass transparatenly. > > Seems bytea is the only good solution, where \\0 becomes NULL. > > Yeah, but now we're talking about what to do before the string gets to > libpq. IOW, what should we do with a nul byte before we hand it off to > PostgreSQL. > > Maybe that answer is just as simple as strip it out, as Baldur suggests. >
That is way too ugly. I'd say either thow an error or truncate the string. I'd rather have the application thow an error, but would understand trunctating the string to the first \0. The reason why I say truncating might be acceptable is that you might, when building the execute statement, do something like strcpy(send_buffer, phs->quoted) knowing that phs->quoted is a null terminated string. So by using strcpy(3) you end up with a valid execute statemnt albiet with some of the input truncated. My vote is for thowing an error on execute. Bruce, The docs for PQescapeString say that it, 'writes an escaped version of the from string to the to buffer replacing special characters so that they cannot cause any harm', but it seems to ignore any \0 characters in the input, so if I do a phs->quoted_len = PQescapeString(phs->quoted, data, len); ... memcpy(sendbuff, phs->quoted, phs->quoted_len); I will get an '\0' in sendbuff? Is that right? The docs say that PGescapeString is for handling untrusted data from the user, so is it still the application's responsibilty to handle the \0 (and any other binary data) before passing it to PQescapeString? -r
