Message-ID: <468989C0.7020601@autoledgers.com.au>
Date: Tue, 03 Jul 2007 07:26:56 +0800
From: Paul Lambert <paul.lambert@autoledgers.com.au>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: Using escape strings in an insert statement.
References: <46898000.7030601@autoledgers.com.au>
	<B98511E0-E97F-4B76-82F0-CE92FC2ACA07@seespotcode.net>
In-Reply-To: <B98511E0-E97F-4B76-82F0-CE92FC2ACA07@seespotcode.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael Glaesemann wrote:
> 
> On Jul 2, 2007, at 17:45 , Paul Lambert wrote:
> 
>> tester=# insert into testing (test_text) values ('abcE'\\'123');
> 
> This should be
> INSERT INTO testing (test_text) values (E'abc\123');
> 
>> The help itself (ch 4.1.2.1) tells me to use double backslash "Thus, 
>> to include a backslash character, write two backslashes (\\). "
> 
> Note that the String Constants section (4.1.2.1) says put the E "before 
> the opening single quote".
> 
> http://www.postgresql.org/docs/8.2/interactive/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS 
> 
> 

Missed that part - my apologies. Time to read the manuals more 
thoroughly it would seem.

>> 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'.
> 
> Also be sure to read the Caution section.
> 
> Using \ as an escape character is the old non-standard PostgreSQL escape 
> syntax that the WARNING (above) is, uh, warning you about. With 
> standard_conforming_strings on (i.e., follow the SQL spec), the 
> backslash is just a backslash character.
> 
>> Which one is the correct syntax and how can I make it not return 
>> anything other than a successful insert?
> 
> Depends on the setting of standard_conforming_strings.
> 
> Michael Glaesemann
> grzm seespotcode net
> 

Looks like it's a toss-up between turning standard_conforming_strings on 
or turning escape_string_warning off, both seem to have the same effect 
in not giving the error anymore.

I'll go with your suggestion though, I guess since it's a new install 
not a previous upgrade of an old it's technically more correct to 
conform to current standards rather than attempt to conform to old behavior.

Cheers for the help - much appreciated.

-- 
Paul Lambert
Database Administrator
AutoLedgers