Literały tekstowe i znaki ucieczki w postgresql

Próba wstawienia znaku zmiany znaczenia do tabeli powoduje wyświetlenie ostrzeżenia.

Na przykład:

create table EscapeTest (text varchar(50));

insert into EscapeTest (text) values ('This is the first part \n And this is the second');

Powoduje ostrzeżenie:

WARNING:  nonstandard use of escape in a string literal

( Przy użyciu PSQL 8.2 )

Czy ktoś wie, jak to obejść?

Częściowo. Tekst został wstawiony, ale ostrzeżenie jest nadal generowane.

Znalazłem dyskusję, w której wskazano, że tekst powinien być poprzedzony literą „E”, jako taki:

insert into EscapeTest (text) values (E'This is the first part \n And this is the second');

To pomijało ostrzeżenie, ale tekst nadal nie był zwracany poprawnie. Kiedy dodałem dodatkowy ukośnik zgodnie z sugestią Michaela, zadziałało.

Takie jak:

insert into EscapeTest (text) values (E'This is the first part \\n And this is the second');

Chłodny.

Znalazłem też dokumentację dotyczącą E:

http://www.postgresql.org/docs/8.3/interactive/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS

PostgreSQL akceptuje również stałe łańcuchowe „escape”, które są rozszerzeniem standardu SQL. Stała łańcuchowa zmiany znaczenia jest określana przez wpisanie litery E (duża lub mała litera) tuż przed otwierającym pojedynczym cudzysłowem, np. E'foo '. (Kontynuując ciąg znaków zmiany znaczenia w wierszach, napisz E tylko przed pierwszym cudzysłowem otwierającym.) W ciągu znaków sterujących odwrotnym ukośnikiem (\) rozpoczyna sekwencję ucieczki odwrotnego ukośnika podobną do litery C, w której kombinacja ukośnika odwrotnego i następującego po nim znaku ( s) reprezentuje specjalną wartość bajtu. \ b to cofnięcie, \ f to wysuw strony, \ n to nowa linia, \ r to powrót karetki, \ t to tabulator. Obsługiwane są również \ cyfry, gdzie cyfry reprezentują ósemkową wartość bajtu, oraz \ xhexdigits, gdzie cyfry szesnastkowe reprezentują szesnastkową wartość bajtu. (Twoim obowiązkiem jest, aby utworzone sekwencje bajtów były poprawnymi znakami w kodowaniu zestawu znaków serwera). Każdy inny znak następujący po odwrotnym ukośniku jest traktowany dosłownie. Dlatego, aby dołączyć znak ukośnika odwrotnego, napisz dwa ukośniki odwrotne (\\). Ponadto pojedynczy cudzysłów można zawrzeć w ciągu znaków sterujących, pisząc \ ', oprócz zwykłego znaku' '.

Ostrzeżenie jest generowane, ponieważ używasz odwrotnych ukośników w łańcuchach. Jeśli chcesz uniknąć tego komunikatu, wpisz polecenie „set standard_conforming_strings = on;”. Następnie użyj „E” przed łańcuchem, włączając ukośniki odwrotne, które postgresql ma zinterpretować.

Uważam, że jest bardzo mało prawdopodobne, aby Postgres obcinał dane wejściowe - albo je odrzuca, albo przechowuje tak, jak jest.

milen@dev:~$ psql
Welcome to psql 8.2.7, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

milen=> create table EscapeTest (text varchar(50));
CREATE TABLE
milen=> insert into EscapeTest (text) values ('This will be inserted \n This will not be');
WARNING:  nonstandard use of escape in a string literal
LINE 1: insert into EscapeTest (text) values ('This will be inserted...
                                              ^
HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.
INSERT 0 1
milen=> select * from EscapeTest;
          text
------------------------
 This will be inserted
  This will not be
(1 row)

milen=>

Naprawdę głupie pytanie: czy jesteś pewien, że ciąg jest obcinany, a nie tylko przerywany w określonym przez ciebie podziale linii (i prawdopodobnie nie pojawia się w twoim interfejsie)? To znaczy, czy spodziewasz się, że pole będzie wyświetlane jako

To zostanie wstawione \ n To nie będzie

lub

To zostanie wstawione

To nie będzie

Jakiego interfejsu używasz? Czy to możliwe, że coś po drodze zjada twoje ukośne ukośne?