23 Jun
2010
23 Jun
'10
11:02 p.m.
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