Re: Welchen 'Data type' nehme ich hier?

On 02/11/2013 07:46 PM, Albe Laurenz wrote:
> Guenther Boelter schrieb:
>>>> ich habe mal wieder ein kleineres Problem im Rahmen der Umstellung von
>>>> MySQL auf PostgreSQL:
>>>>
>>>> Welchen 'data type' nehme ich sinnvollerweise fuer
>>>>
>>>> A:) PDF-Dateien (ca. 25 KB gross)
>>>>
>>>> B:) XML-Dateien (ca. 10-20 KB gross)
>>>>
>>>> Die PDF-Dateien habe ich zunaechst mal als BYTEA gespeichert, die
>>>> XML-Dateien als TEXT.
>>> Dass sollte okay sein. Es gibt auch einen speziellen XML-Datentyp:
>>> http://www.postgresql.org/docs/current/interactive/datatype-xml.html
>>>
>>> Ob dieser besser als TEXT ist mußt Du entscheiden, der XML-Datentyp hat
>>> halt noch z.B. Konsistenzprüfungen und so.
>>>
>>>
>>>> Bei den PDF-Dateien konnte ich es bisher noch nicht pruefen, aber bei
>>>> den XML-Dateien scheint PostgreSQL die enthaltenen '\n' in '\012'
>>>> unzuwandeln. Letzt sich Letzeres irgendwie verhindern?
>>> Unwahrscheinlich. PostgreSQL vergreift sich nicht an den Daten.
>>> Im übrigen ist '\n' oktal '\012'. Evtl. ist was bei Konvertierungen
>>> zwischen Windows / Linux kapott gegangen.
>> kurzes Feedback zu dem Problem mit dem '\n' bzw. '\012':
>>
>> Es ist tatsaechlich ein Fehler in der Library den MySQL einfach ignoriert hat. PostgreSQL dagegen gibt
>> folgende Warnung aus:
>>
>> WARNING: nonstandard use of \\ in a string literal
>> LINE 1: EXECUTE qpsqlpstmt_1 ('<?xml version="1.0" encoding="UTF-8"?...
>> ^
>> HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
>>
>> Dafuer musste ich allerdings auch erst den Debugger anwerfen.
> Es handelt sich um eine PostgreSQL-Version vor 9.1, richtig?
>
> Es gibt mehrere Lösungen:
>
> 1) standard_conforming_strings = on
> 2) Wörtlich gemeinte Backslashes verdoppeln und die String-Konstante
> mit einem "E" einleiten: EXECUTE s (E'<?xml ... \\n ...>');
> 3) Extended Query Protocol (mit Parametern) verwenden
>
> Liebe Grüße,
> Laurenz Albe
>
Hallo Laurenz,

Ja, es handelt sich um Version 8.4.13 auf einem CentOS-Server.

Kurz bevor Deine Mail hier einging hatte ich gerade Deinen Beitrag hier
-
https://groups.google.com/forum/?fromgroups=#!topic/comp.databases.postgresql/y3u3e6LrtBw
- gefunden.

Der Fehler lag aber tatsaechlich in dem von mir eingesetzten
(proprietaeren) NCReport, von dem ich zum Glueck aber auch den Source
besitze. Mit Hilfe des Supports von Nocisoft konnte ich den Fehler dann
lokalisieren und 'an der Quelle' beheben.

Das bisher keiner ueber den Fehler gestolpert ist kann ich mir nur so
erklaeren, dass niemand die Lib zusammen mit PostgreSQL einsetzt. Unter
MySQL wird dieser Fehler zwar auch 'angemeckert', dann aber einfach
ignoriert.

Ich sehe schon, ich haette viel frueher zu PostgreSQL wechseln sollen ...

Herzliche Gruesse

Guenther
Davao City, Philippines, Planet Earth, 32.0 °C im Schatten!

--
DavaoSOFT, the home of ERPel
ERPel, das deutsche Warenwirtschaftssystem fuer LINUX
http://www.davaosoft.com