Put back plpython_unicode_2.out for SQL_ASCII case.

This alternative expected output file is required when using SQL_ASCII
as the client and server encoding. The python encoding conversion used to
throw an error on that, but it is now accepted and you get the UTF-8
representation of the string. I thought that case was already covered by
the other expected output files, but the buildfarm says otherwise.

This is only required on REL9_2_STABLE. In 9.1, we explicitly set
client_encoding to UTF-8 to avoid this.

1 files changed, 50 insertions, 0 deletions

diff --git a/src/pl/plpython/expected/plpython_unicode_2.out b/src/pl/plpython/expected/plpython_unicode_2.out
new file mode 100644
index 00000000000..7617e41a0b1
--- /dev/null
+++ b/src/pl/plpython/expected/plpython_unicode_2.out
@@ -0,0 +1,50 @@
+--
+-- Unicode handling
+--
+CREATE TABLE unicode_test (
+	testvalue  text NOT NULL
+);
+CREATE FUNCTION unicode_return() RETURNS text AS E'
+return u"\\x80"
+' LANGUAGE plpythonu;
+CREATE FUNCTION unicode_trigger() RETURNS trigger AS E'
+TD["new"]["testvalue"] = u"\\x80"
+return "MODIFY"
+' LANGUAGE plpythonu;
+CREATE TRIGGER unicode_test_bi BEFORE INSERT ON unicode_test
+  FOR EACH ROW EXECUTE PROCEDURE unicode_trigger();
+CREATE FUNCTION unicode_plan1() RETURNS text AS E'
+plan = plpy.prepare("SELECT $1 AS testvalue", ["text"])
+rv = plpy.execute(plan, [u"\\x80"], 1)
+return rv[0]["testvalue"]
+' LANGUAGE plpythonu;
+CREATE FUNCTION unicode_plan2() RETURNS text AS E'
+plan = plpy.prepare("SELECT $1 || $2 AS testvalue", ["text", u"text"])
+rv = plpy.execute(plan, ["foo", "bar"], 1)
+return rv[0]["testvalue"]
+' LANGUAGE plpythonu;
+SELECT unicode_return();
+ unicode_return 
+----------------
+ €
+(1 row)
+
+INSERT INTO unicode_test (testvalue) VALUES ('test');
+SELECT * FROM unicode_test;
+ testvalue 
+-----------
+ €
+(1 row)
+
+SELECT unicode_plan1();
+ unicode_plan1 
+---------------
+ €
+(1 row)
+
+SELECT unicode_plan2();
+ unicode_plan2 
+---------------
+ foobar
+(1 row)
+