Thanks again Oleg.
ubuntu 12.04 server LTS has version 0.12.4 in package management. Guess
I will better install this using the suggested method on the homepage.
Am 05.06.2013 10:12, schrieb Oleg Broytman:
> [CC to the mailing list]
> On Wed, Jun 05, 2013 at 09:57:01AM +0200, dev@... wrote:
>> Hi Oleg,
>> thanks for your fast reply. It pointed me to the solution. postgres
>> 9.1 on ubtuntu server 12.04 has standard_conforming_strings enabled
>> by default.
>> Turning it off solved my problem.
> Turning standard_conforming_strings off is not required since
> SQLObject 1.2: http://sqlobject.org/News.html#sqlobject-1-2-0
> "Support for PostgreSQL 7.* is dropped. The minimal supported version
> of PostgreSQL is 8.1 now.
> Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
> if the string contains characters escaped with backslash."
>> Am 05.06.2013 09:15, schrieb Oleg Broytman:
>>> On Wed, Jun 05, 2013 at 08:54:20AM +0200, Thomas Siemion <dev@...> wrote:
>>>> Hey folks,
>>>> I was wondering why the sqlrepr from converters.py is escaping
>>>> linebreaks and other chars for postgres.
>>>> I'm talking about this piece of code:
>>>> sqlStringReplace = [
>>>> ("'", "''"),
>>>> ('\\', '\\\\'),
>>>> ('\000', '\\0'),
>>>> ('\b', '\\b'),
>>>> ('\n', '\\n'),
>>>> ('\r', '\\r'),
>>>> ('\t', '\\t'),
>>>> This causes for e.g. \ to multiply. when I comment out everything but
>>>> the escaping of the single quote everything works as aspected. I don't
>>>> see the reason why this is done in the first place.
>>>> Could anyone please explain this to me and why this is done when saving
>>> "PostgreSQL also accepts "escape" string constants, which are an
>>> extension to the SQL standard. An escape string constant is specified by
>>> writing the letter E (upper or lower case) just before the opening
>>> single quote, e.g., E'foo'. (When continuing an escape string constant
>>> across lines, write E only before the first opening quote.) Within an
>>> escape string, a backslash character (\) begins a C-like backslash
>>> escape sequence, in which the combination of backslash and following
>>> character(s) represent a special byte value, as shown in Table 4-1."
>>> Also see https://dev.mysql.com/doc/refman/5.0/en/string-literals.html
>>>> but not undone when loaing?
>>> Because there is no need to "undone" anything. The backend doesn't
>>> store escaped values -- it stores normal values that it sends back on