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