Thread: PQgetlength vs. octet_length()

Michael Clark <codingninja@gmail.com> wrote:
> Hello - am I in the wrong mailing list for this sort of problem? :-/
Probably.  If you check here:
http://www.postgresql.org/community/lists/
You'll find this description for the list:
"The PostgreSQL developers team lives here. Discussion of current
development issues, problems and bugs, and proposed new features. If
your question cannot be answered by people in the other lists, and it
is likely that only a developer will know the answer, you may re-post
your question in this list. You must try elsewhere first!"
Your question sounds appropriate for the pgsql-general list.
>> I have a value inserted into a bytea column, which is about 137megs
>> in size.
>>
>> If I use octet_length() to check the size of the column for this
>> specific row I get this:
>> TestDB=# SELECT octet_length(rawdata) FROM LargeData;
>>  octet_length
>> --------------
>>     143721188
>>
>> When fetching the row through the C API, and I use PQgetlength() on
>> the column of the row in question I get:
>> (gdb) p (int)PQgetlength(result, rowIndex, i)
>> $3 = 544453159
As long as I'm replying, I'll point out that the relative sizes would
make sense if you were using an interface which got the text
representation of the bytea column, since many bytes would be
represented in octal with a backslash escape (four characters per
byte).
-Kevin

On Tue, Aug 18, 2009 at 4:04 PM, Michael Clark<codingninja@gmail.com> wrote:
> Hello - am I in the wrong mailing list for this sort of problem? :-

Probably but it's also a pretty technical point and you're programming
in C so it's kind of borderline.

If you're using text-mode then your datum that you're getting from
libpq is a text representation of the datum. For bytea in released
versions that means anything which isn't a printable ascii character
will be octal encoded like \123. You can use PQunescapeBytea to
unescape it.

If you use binary encoding then you don't have to deal with that.
Though I seem to recall there is still a gotcha you have to worry
about if there are nul bytes in your datum. I don't recall exactly
what that meant you had to do though.

-- 
greg
http://mit.edu/~gsstark/resume.pdf

Greg Stark wrote:
> If you use binary encoding then you don't have to deal with that.
> Though I seem to recall there is still a gotcha you have to worry
> about if there are nul bytes in your datum. I don't recall exactly
> what that meant you had to do though.

As far as I know, it only means that you shouldn't use strcpy, strlen
and friends on a binary string.

Yours,
Laurenz Albe