좋게 바뀌었습니다. :)

template1=# select version();
                                                version
--------------------------------------------------------------------------------------------------------
 PostgreSQL 8.0.0rc2 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.3.1 (mingw special 20030804-1)
(1건 있음)

template1=# show server_encoding;
 server_encoding
-----------------
 SQL_ASCII
(1건 있음)

template1=# show client_encoding;
 client_encoding
-----------------
 SQL_ASCII
(1건 있음)

template1=# create table t (a varchar(4));
CREATE TABLE
template1=# insert into t values ('우리나라');
ERROR:  value too long for type character varying(4)

-- 데이터베이스 문자셋이 아스키이기 때문에, 우리나라는 여덟글자로 처리함.

template1=# insert into t values ('우리');
INSERT 153287 1
template1=# copy t from stdin;
한 줄에 한 레코드씩 데이터를 입력하고
자료입력이 끝나면 backslash 점 (\.) 마지막 줄 처음에 입력합니다.
>> 무
>> 궁
>> 화
>> 꽃
>> 이
>> 피
>> 었
>> 습
>> 니
>> 다
>> 햇
>> 햏
>> \.
template1=# select a from t order by a;
  a
------
 궁
 꽃
 니
 다
 무
 습
 었
 우리
 이
 햏
 피
 햇
 화
(13건 있음)

-- 데이터베이스 문자셋이 SQL_ASCII일 경우, 확장완성형글자의 정렬문제, 버그 아님. 일단 정렬됨.

template1=# explain select dong from zipcode where dong like '공항%';
                                                 QUERY PLAN
------------------------------------------------------------------------------------------------------------
 Index Scan using zipcode_dong_i on zipcode  (cost=0.00..745.88 rows=222 width=28)
   Index Cond: (((dong)::text >= '공항'::character varying) AND ((dong)::text < '공해'::character varying))
   Filter: ((dong)::text ~~ '공항%'::text)
(3건 있음)
-- 깔끔하게 like 연산에서도 인덱스를 사용할 수 있음.

살펴보듯이 많이 개선되었습니다.

이것은 단지 실험일 뿐, 실무에서는 그래도 unicode로 작업하는 것이 모든 면에서 잃는 것 보다 얻는 것이 많습니다.