[sr-dev] PostgreSQL problems with Kamailio_3.0.2

[Klaus Feichtinger]

According information I found in the PostgreSQL manual, the data type
"BYTEA" is already representing a postgres-like binary data format.

Excerpt of the documentation
(http://www.postgresql.org/docs/8.3/static/datatype-binary.html):
"The bytea data type allows storage of binary strings. [...] The SQL
standard defines a different binary string type, called BLOB or BINARY
LARGE OBJECT. The input format is different from bytea, but the provided
functions and operators are mostly the same."

"Real" BLOB (according SQL definition) is therefore not supported by
postgres. This page (documentation of binary data types) includes
examples of literal escaped octets, too. Maybe is is helpful for developers.

Klaus

Am 23.06.2010 18:05, schrieb Klaus Darilion:
>
>
> Am 20.06.2010 14:39, schrieb Klaus Feichtinger:
>> 4) I don’t know if the parser might be influenced by a WARNING that is
>> generated by the postgresql daemon whenever an entry into the presentity
>> table is done (including XML body). From Kamailio log output I saw that
>> the special characters “#011” and “#012” are included in the XML body. I
>> guess that is the octal notation of \t (horizontal tab) and \n
>> (newline).
>>
>> However, postgresql generates an error message that looks like
>> following:
>>
>> /WARNING:  nonstandard use of \\ in a string literal at character 162/
>>
>> HINT:  Use the escape string syntax for backslashes, e.g., E'\\'.
>>
>> Maybe this has some influence on the parser problem, too. Because in
>> this version of Postgresql the parameter “standard_conforming_strings”
>> is implicitly on – just for previous versions it could be set to off.
>> That means, that any backslash symbol (\) is interpreted as standard
>> character (no escape). Therefore the queried result of the database does
>> no longer include \n and \t.
>
> I just wonder if this can be solved by storing the body as BLOB
> instead of strings. Could you test using a BLOB for the body (in
> database and presence modules)
>
> regards
> klaus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20100623/4fa098b5/attachment.htm>