ECPG로 Embedded SQL 프로그래밍하기

공개 데이터베이스 서버 PostgreSQL (6) -ECPG로 Embedded SQL 프로그래밍하기 한동훈 /리눅스 코리아 대표 ddoch@hitel.kol.co.kr

PostgreSQL 버전 6.3 얼마나 달라졌나? 3월 1일자로 PostgreSQL의 6.3 버전이 발표되었다. 사실 PostgreSQL 개발팀에서는 작년 연말 이전에 발표하겠다고 했었다. 6.2.1 버전 발표 이후로 상당한 시간이 흘러 6.3 버전이 발표된 만큼 공개 데이터베이스 서버 사용자들은 새로운 버전에 많은 기대를 걸고 있는 것 같다. 그 오랜 기간동안만큼 많은 것들이 추가되었고 달라졌다. PostgreSQL 6.0이 Postgres95의 장벽을 뛰어넘은 전 분야에서의 획기적인 버전이었다고 한다면, PostgreSQL 6.3은 6.0 이후에 가장 획기적인 변화를 가져왔다고 볼 수 있다. PostgreSQL 개발팀에서는 6.0 이후에 SQL92 표준을 지원하고 여러분은 이제 그 혜택을 마음껏 누릴 수 있게 되었다. 여러분은 이제 그 혜택을 마음껏 누릴 수 있게 되었다. PostgreSQL 사용자들에게는 이제 또 한번의 업그레이드 전쟁을 해야 할 뚜렷한 이유가 주어진 셈이다. 이제 6.3에서 달라진 기능을 살펴보자. SUBSELECT의 지원 오랫동안 PostgreSQL 사용자의 바램 중의 하나인 SUBSELECT를 마침내 지원한다. 보조 질의 중에 EXISTS, IN, ALL, ANY 예약어를 함께 사용할 수 있다. PRIMARY KEY와 UNIQUE절 지원 SQL92의 PRIMARY KEY와 UNIQUE절을 인덱스를 사용하여 구현하였다. FOREIGN KEY는 아직 구현되어있지 않다. SQL 92의 여러 상수값 지원 SQL92에는 상황에 따라 사용할 수 있는 여러 상수값들이 정의되어 있다. PostgreSQL 6.3 버전에서도 이러한 것들 중 여러 개를 지원한다. CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, CURRENT_USER를 비롯한 가변상수와 TRUE, FALSE를 비롯한 논리상수, IS TRUE, IS FALSE, IS NOT TRUE, IS NOT FALSE를 비롯한 조건절을 지원한다. 사용자 PROCEDURAL LANGUAGE 생성 지원 사용자가 직접 함수에 사용할 언어를 작성할 수 있도록 해주는 유용한 기능이다. 일반 데이터베이스 사용자는 직접 사용할 기회가 없겠지만, 개발자라면 관심을 가질만 하다. 구문은 다음과 같다. create function plsample_call_handler () returns opaque as '/usr/local/pgsql/lib/plsample.so' language 'C'; create procedural language 'plsample' handler plsample_call_handler lancompiler 'PL/Sample'; language 'C'; 새로운 PostgreSQL 프로시저 언어(PL)지원 오라클에서 주로 사용하는 PL/SQL과 유사한 프로시저 언어이다. PL은 스크립트 언어이면서도 SQL의 기능을 강력하게 수행하는 프로시저 중심의 언어라고 볼 수 있다. PostgreSQL에서는 PL/TCL을 그 첫 번째로 제공한다. 자주 호출되는 함수의 빠른 속도 유지 자주 사용되는 함수 중 몇 몇에 대해 즉각적인 처리를 함으로써 속도가 향상되었다. 락킹에서의 향상 락킹은 데이터베이스 시스템에서 매우 중요한 위치를 차지한다. 교착상태라고 부르는 실제 deadlock을 감지함으로써 더 이상의 time out을 방지한다. 아울러 인덱스를 생성할 때에 공유 락(shard lock)을 사용한다. 그리고 사용자가 특정 데이터베이스의 테이블을 트랜잭션 구간 중에서 독점 락(exclusive lock)을 걸 수 있도록 허용하는 LOCK 명령을 사용할 수 있다. UNIX 도메인 소켓 지원 벡엔드와 프론트엔드 라이브러리에서 UNIX 도메인 소켓을 지원한다. LIKE 와 ~, !~ 구문에 인덱스 사용 UNION, GROUP, DISTINCT의 선별적 지원 SELECT 시에 UNION을 지원하고, INSERT 시에 UNION, GROUP, DISTINCT를 지원한다. varchar의 디스크 저장형태 변경 데이터형이 varchar인 데이터는 디스크에 저장될 때, 필요한 부분만 저장된다. 즉, varchar(100)이라고 해도 실제 데이터가 8바이트라면 그만큼만 저장된다. .psqlrc 기동파일 지원 psql을 사용할 시에 사용자가 여러 가지를 미리 편리하게 설정할 수 있도록, 홈디렉토리에 .psqlrc 파일을 만들 수 있도록 지원한다. $HOME/.psqlrc 파일에는 psql에서 수행할 수 있는 모든 명령이 올 수 있다. PostgreSQL에서 psql을 시작할 때마다 날짜형을 ISO로 맞추고, vacuum 명령을 수행한다면, $HOME/.psqlrc 파일에 다음과 같은 내용을 적어보자. vacuum; set DateStyle to 'ISO'; 다음은 psql을 가동할 때의 화면이다. 시간 여행(time travel) 기능 제거 말 많던 시간 여행 기능이 드디어 제거되었다. 이 기능은 유용하긴 하지만, 데이터베이스 시스템의 속도를 저하시키는데 한몫을 해왔다. 오래 전에 지워진 데이터까지도 완전히 복구할 수 있도록 지원해 줌으로써 사용자에게 편리성을 제공해오기는 했지만, 그 때문에 데이터 처리 속도가 상당히 늦어졌기 때문이다. 이제 SQL 질의시에 데이터를 회수하는 데까지 걸리는 시간은 더욱 단축되었다. 하지만 시간 여행 기능은 트리거 기능을 사용하면 충분히 재생할 수 있으며, 실제로 6.2에서 시간 여행을 위한 일반적인 트리거 함수가 이미 추가되었다. 새로워진 문서들 필자뿐만이 아니라 PostgreSQL에서 참조할 만한 문서가 너무 적다고 생각해온 여러분들에게는 정말 반가운 일이 아닐 수 없다. PostgreSQL 사이트(www.postgreSQL.org)에 몇 달 전부터 PostgreSQL 관련 문서화 프로젝트가 새롭게 추진되고 있다. 이와 함께 나타난 새로운 문서들은 PostgreSQL 매니아들에게 정말 갈증날 때의 오아시스가 아닐까 싶다. 6.3 버전에는 모두 postgres 매뉴얼과 관리자 매뉴얼, 프로그래머 매뉴얼, 튜토리얼과 사용자 매뉴얼이 분리된 채로 소스 배포본의 doc 디렉토리에 들어있다. 모두 뽑아본다면 두꺼운 책 한 권 분량을 방불케 할 것이다. 중복되는 내용이 더러 있다. 내장 언어 ECPG 지원 ECPG는 PostgreSQL 6.3 이전까지만 해도 Linus Tolke(linus@epact.se)씨가 작성해서 PostgreSQL과는 별도로 지원하던 것이었는데, 6.3에 들어오면서 내부에 포함했다. ECPG는 일종의 C에서 사용하는 내장 SQL이다. 이번 호의 주제가 ECPG이므로 이후에서 충분히 설명하도록 하자. 그 외에 달라진 점 이외에도 6.3 버전에서 달라진 것들이 많이 있다. PSQL에서 지원하는 기능도 확장되었으며, bin 디렉토리에 포함된 바이너리도 상당히 많아졌다. 아울러 중요한 점 한가지를 언급하자면 varchar()나 text() 대신에 기본적으로 char()를 쓰기를 권장한다. 왜냐하면 6.3에 들어와서 이 둘보다 char()가 상당히 속도가 빨라졌기 때문이다. 그리고 뷰에서도 뷰가 기반하고 있는 테이블과는 별도로 권한을 설정할 수 있게 되었다. 보안을 위해 GRANT, REVOKE 명령을 사용하여 조정하는 것이 좋다. 데이터베이스 접근을 제한하는 pg_hba.conf도 좀 더 강화되었다. 자세한 이야기는 man pg_hba.conf로 살펴보기 바란다. 그리고 pg_passwd 인증 데이터베이스가 UNIX 시스템의 /etc/passwd와는 분리가 되었다. 파이톤 인터페이스가 PyGreSQL 2.0으로 새로워졌으며, PostgreSQL에서 사용하는 형변환 연산자인 '::'는 상수가 아닌 값도 형변환 할 수 있게 되었다. 이외에도 시스템 카탈로그(데이터사전)도 몇 가지 변화되었으며, 여러 가지의 버그가 수정되었다. 자세한 내용은 소스 디렉토리의 HISTORY 파일을 참고하기 바란다. PostgreSQL에서 멀티 바이트 사용하기 PostgreSQL 6.3의 설치방법은 이전의 6.x 버전과 동일하다. PostgreSQL에서 다중 바이트를 처리할 수 있도록 해주는 패치를 만들고 있는 Tatsuo Ishiu씨는 이번에도 어김없이 6.3 버전을 위한 패치를 재빠르게 공급하고 있다. 다음 사이트에서 이러한 패치를 얻을 수 있다. ftp://ftp.sra.co.jp/pub/cmd/postgres/6.3/patches/6.3mbPL1.patch.gz PostgreSQL 6.3의 압축을 푼 곳에서 다음과 같이 패치하면 된다. #gzip -dc 6.3mbPL1.patch.gz | patch -p0 이번 패치판은 예전의 일본어를 비롯한 2바이트권 사용자만을 위한 것이 아니라 그야말로 멀티바이트 사용자를 위한 것이다. 즉, 기존의 7비트에서 제대로 표현하기 힘든 독일어 등의 8비트 문자 사용자와 2바이트의 동양권 문자 사용자와 2바이트 이상의 UNICODE도 지원하고 있다. 이 패치를 적용하려면 src/Makefile.custom 파일에 예전의 JP=1 대신, MB=EUC_KR이라는 한 줄을 적어주면 된다. 사용할 수 있는 코드는 표와 같다. AIX Digital Unix (Alpha) FreeBSD FreeSCO HP-UX (PA-RISC) IRIX Linux (Alpha, m68k, x86) NetBSD (x86?) OpenStep/NextStep (x86) [xscanimage/xcam 테스트 안됨] OS/2 Solaris (SPARC) SunOS (SPARC) 사용하고자 하는 코드의 이름을 src/Makefile.custom에 적어주면 된다. 이들 패치를 적용시키면, 테이블명과 테이블 내의 컬럼명, 정규 표현식 검색에서 한글을 사용할 수 있다. ECPG - C에서 사용하는 내장 SQL ECPG는 PostgreSQL의 Pro*C이다. 앞서 잠시 언급한 PL은 주로 SQL 측면에서 바라본 확장이지만 ECPG는 C언어에서 바라본 SQL 확장이다. 즉, ECPG는 C언어로 데이터베이스를 처리하는 데 편리함을 주기 위해서 개발된 전처리기이다. 사실 ECPG의 장점은 데이터베이스의 값을 C 변수로 쉽게 가져올 수 있다는 것이다. LIBPQ를 사용하는 응용 프로그램에서는 데이터베이스의 특정 테이블, 칼럼의 값을 얻으려면 여러 번 작업을 하여야 한다. 이러한 반복작업과 지루한 작업을 제거하여 더욱 손쉽게 데이터베이스 처리를 할 수 있도록 도와주는 도구가 바로 ECPG이다. ECPG는 다른 RDBMS의 내장 SQL로 쓰여진 프로그램을 PostgreSQL로 포팅하는 데에도 사용할 수 있다. ECPG - 내장 SQL의 전처리기 ECPG는 전처리기이다. 내장 SQL로 작성한 소스를 순수 C 소스로 변환하는 일을 한다. SQL을 충실하게 공부해본 경험이 있다면, 다음과 비슷한 코드를 본 기억이 있을 것이다. EXEC SQL BEGIN DECLARE SECTION; int i; EXEC SQL END DECLARE SECTION; EXEC SQL CREATE DATABASE testbase; EXEC SQL GRANT DBA TO mylove; EXEC SQL CREATE TABLE foo ( bar int ); 여기에서 앞 부분의 선언 영역만 제외한다면 나머지 EXEC SQL 다음은 우리가 익히 보아왔던 SQL 질의문장이다. 이들 코드는 ECPG 전처리기에 의해 순수 C 소스로 변환된다. 마지막 구문이 순수 C 소스로 최종적으로 변환된다면, 다음과 비슷할 것이다. PQexec(conn, "CREATE TABLE foo ( bar int );"); 물론, EXEC SQL과 같은 내장 SQL 구문이 ECPG를 거치면 ECPGdo라는 중간 라이브러리 함수를 거치게 된다. P함수는 이 ECPG 라이브러리 루틴내부에서 호출된다. 위에서와 같은 내장 SQL은 직접 C 함수를 작성하는 것보다 쉽다. 그리고 더욱 직관적이어서 알아보기도 명확하다. 아울러 데이터베이스의 값을 C 변수로 넘기는 것은 아주 편리하게 디자인되어 있다. ECPG는 구문 분석기로 내장 SQL 구문을 읽어들여 정해진 규칙에 따라 C 소스를 만들어 내는 역할을 하는 것이다. ECPG에서 내장 SQL 구문을 어떻게 C 소스로 변환하는지 잠시 살펴보자. 먼저, exec sql begin declare section;과 exec sql end declare section; 사이에 있는 모든 선언 구문은 그대로 출력된다. 이 둘 사이에 있는 변수는 ECPG 내부에서 인덱스 처리된 변수 목록에 들어간다. 그리하여 내장 SQL 구문에서 이들 변수가 사용되었을 시에 적절한 처리를 하게 되는 것이다. 각각 번역되는 예는 다음과 같다. VARCHAR var[180]; --> struct varchar_var { int len; char arr[180]; } var; exec sql include filename; --> #include <filename.h> exec sql connect 'database'; --> ECPGconnect("database"); exec sql open cursor; --> 무시 exec sql commit; --> ECPGcommit(_LINE_); exec sql rollback; --> ECPGrollback(_LINE_); VARCHAR는 특별한 구조체 문장으로 번역되고, include 문장은 C의 #include 문장으로 변환된다. 그리고 open cursor 문장은 그냥 무시된다. 그 외의 몇 가지 내장 SQL문은 적절한 ECPG 함수로 변환된다. 함수 내에서 _LINE_ 인자는 디버깅을 위해 전달되는 것일 뿐이다. 추가적으로, exec sql include sqlca; 구문을 사용하여 sqlca.h 헤더파일을 포함하면, 다음과 같은 구조체가 포함된다. struct sqlca { int sqlcode; struct { int sqlerrml; char sqlerrmc[1000]; } sqlerrm; } sqlca; 이 구조체에서 sqlca.sqlcode는 에러 상황을 반영한다. 주어진 질의와 데이터베이스 정의가 일치하지 않는 것과 같은 치명적인 에러가 발생하였을 경우에 sqlca.sqlcode의 값은 음수이다. 그렇지 않고, 더 이상 회수할 데이터가 없는 것과 같은 보통의 에러가 발생하였을 경우에 sqlca.sqlcode의 값은 양수이다. 프로그래머가 응용 프로그램을 짤 때 다음과 같은 코드를 사용하게 될 것이다. exec sql whenever not found do set_not_found(); exec sql whenever sqlerror sqlprint; 첫 번째 루틴은 말 그대로 '데이터를 발견하지 못했을 경우에는 set_not_found() 함수를 실행하라'는 것이다. '데이터를 발견하지 못했을 경우'라는 것은 평범한 에러에 속하므로 sqlca.sqlcode가 0보다 큰 경우(양수)일 때이다. 두 번째 루틴은 'SQL에서 에러가 발생하였을 경우에는 에러 문장을 출력하라'는 것이다. 여기서 SQL 에러는 보통 치명적인 에러를 일컫는다. 따라서 sqlca.sqlcode가 0보다 작은 경우(음수)일 때이다. sqlca.sqlcode를 검사하는 시점은 매번의 사건이 발생한 직후이다. 따라서 위의 두 내장 SQL문은 출력되는 C 코드 내에서 다음과 같은 문장으로 이벤트가 발생한 이후마다 추가된다. 여기에서 SQLCODE는 ecpglib.h 파일에 sqlca.sqlcode로 정의되어 있다. if (SQLCODE > 0) set_not_found(); if (SQLCODE < 0) sqlprint(); 내장 SQL을 C 소스로 변환하였다면, 이제 C 소스를 실행 가능한 바이너리로 컴파일해야 할 차례이다. C 소스를 컴파일하는 데에는 ECPG 라이브러리가 필요하다. libecpg.a, libecpg.so가 그것이다. 그리고 ECPG 라이브러리는 libpq를 사용한다. 따라서 순수 C 소스를 컴파일할 때에는 ECPG 라이브러리와 libpq를 순서대로 -lecg -lpq와 같이 링크시켜야 한다. ECPG 라이브러리는 정상적으로 설치하였다면 /usr/local/pgsql/lib에 있을 것이다. 이 라이브러리 루틴에는 두 개의 숨겨진 함수가 있다. ECPGdebug (int, FILE *stream) int가 0이 아니면 디버깅이 수행된다. 실제로 디버깅 정보를 수록하는 함수는 ECPGdo이다. 이 함수는 EXEC SQL COMMIT, EXEC SQL ROLLBACK, EXEC SQL CONNECT 이외의 모든 SQL 구문에서 호출된다. 호출된 ECPGdo 함수는 확장된 SQL 문자열과 입력 변수값이 삽입된 문자열을 기록하기 때문에, SQL 구문에서 에러를 검사하는데 매우 유용하다. LIBPQ가 제공하는 PQtrace 루틴보다는 훨씬 명확하고 실제 사용할 때에 많은 도움이 될 것이다. ECPGstatus() 현재 데이터베이스에 접속되어 있으면 TRUE를 돌려주고, 아니면 FALSE를 돌려준다. testecpg.pgc /* testecpg.pgc - Embedded SQL ECPG의 테스트 작성: PostgreSQL 배포본에 들어있는 testlibpq.c를 ECPG를 사용하여 재 작성함. 내용: template 1 데이터베이스에 접속하여 pg_database 시스템 카탈로그의 내용을 출력함. 날짜: 1998년 3월 10일 작성자: 한동훈 ddoch@hitel.kol.co.kr */ #include <stdio.h> exec sql include sqlca; extern void ECPGdebug (int n, FILE *debug); exec sql whenever not found do set_not_found(); exec sql whenever sqlerror sqlprint; static int not_found = 0; static void set_not_found() { not_found = 1; } int main() { exec sql begin declare section; struct ca_pg_database_struct { char datname[32]; int datdba; char datpath[32]; } ca_pg_database; exec sql end declare section; FILE *debug; if ((debug = fopen("/tmp/trace.out", "w")) != NULL) ECPGdebug(1, debug); exec sql connect 'template1'; exec sql declare myportal cursor for select *from pg_database; exec sql open myportal; printf("%-20s%-20s%-20s＼n＼n", "데이터베이스 이름", "데이터베이스 관리자", "데이터베이스 경로"); while (!not_found) { exec sql fetch myportal into : ca_pg_database; if (!not_found) { printf ("%-20s%-20d%-20s＼n", ca_pg_database.datname, ca_pg_database.datdba, ca_pg_database.datpath); } exec sql close myportal; exec sql commit; if (debug != NULL) fclose(debug); return 0; } ECPG의 설치와 기본 사용법 ECPG를 설치하는 방법은 아주 간단하다. PostgreSQL 6.3 안에 있는 ECPG를 설치해보자. 만일 PostgreSQL이 6.3 버전 미만이라면 ECPG의 예전의 0.2 버전을 구해서 테스트 해볼 수 있긴 하지만 권하는 바는 아니다. PostgreSQL 6.3 버전에 포함된 ECPG는 1.0인데, 이 버전은 예전의 0.x 버전보다는 상당히 다듬어져서 비로소 쓸 만하게 되었다고 보기 때문이다. ECPG는 LIBPQ를 사용함으로 인해 PostgreSQL의 버전과 서로 맞아야 한다. 따라서 여기서는 PostgreSQL 6.3과 함께 ECPG를 설치하는 것으로 간주한다. PostgreSQL 6.3은 이미 설치하였다고 가정한다. postgres 계정으로 들어가서 ecpg 디렉토리로 이동해서 make install을 한다. $ cd postgresql-6.3/src/interfaces/ecpg $ make install ecpg 프로그램들은 /usr/local/pgsql/을 기준으로, 바이너리는 bin/에, 라이브러리는 lib/에, 헤더 파일은 include/에 설치될 것이다. ecpg에 공유 라이브러리가 포함되어 있으므로, 마지막으로 root로 들어가서 ldconfig를 수행하는 것을 잊지 말자. # ldconfig 이제 ecpg를 실행시켜 보면 다음과 같은 메시지가 뜰 것이다. $ ecpg ecpg - the postgresql preprocessor, version: 1.0.0 Usage: ecpg: [-v] [-d] [-o outout file name] file1 [file2] -v 옵션은 버전 정보를 보여주는 것이고, -d 옵션은 전처리시에 디버깅 정보를 보여준다. -o 옵션은 전처리되어서 출력될 파일의 이름을 지정해주는 것이고, 뒤의 file1...은 전처리할 내장 SQL 소스를 지정하는 것이다. ECPG로 작성하는 예제 프로그램 이제, ECPG로 간단한 예제 프로그램을 작성해보자. 지난 2월호에서 LIBPQ를 설명할 때 잠시 살펴본 적이 있는 testlibpq.c를 ECPG를 사용해서 동일하게 변환해 보도록 하자. testlibpq.c는 stc/test/examples/에 있다. 새롭게 재작성하는 프로그램은 testecpg.pgc라고 하겠다. 이 프로그램의 컴파일은 다음과 같이 한다. 전처리 단계 $ ecpg -o testecpg.c testecpg.pgc 컴파일 단계 $ gcc -o testecpg testecpg.c -I/usr/local/pgsql/include -L/usr/local/pgsql/lib -lecpg -lpq 일일이 이렇게 긴 명령을 입력하는 것은 번거로울 것이다. 간단하게 다음과 같은 스크립트를 사용하여 편리하게 컴파일하도록 하자. #!/bin/sh # name : ec CC=gcc CFLAGS="-lecpg -lpq -L/usr/local/pgsql/lib -I/usr/local/pgsql/include" ECPG_OPTIONS= if [ $# -le 0 ]; then echo "usage: $0 <ecpg source>" exit fi PREFIX=${1%.*} ecpg $ECPG_OPTIONS -o ${PREFIX}.c $1 $cc -o $PREFIX ${PREFIX}.c $CFLAGS 위의 파일을 ec로 만들고, chmod 명령으로 실행가능하게 만들어 놓자. $ chmod +x ec ecpg 소스를 전처리하고 컴파일하기 위해서는 그냥 ec filename으로 사용하면 된다. $ ./ec testecpg.pgc 정상적으로 처리되면, 전처리된 소스는 testecpg.c로 만들어질 것이고, 실행가능한 바이너리는 testecpg로 만들어질 것이다. 컴파일된 testecpg를 실행한 결과는 다음과 같다. 디버깅 정보를 담은 파일의 내용은 다음과 같다. ECPG는 어디까지 와있는가? ECPG의 한계와 단점은 무엇인가? 조금 덩치가 큰 응용 프로그램을 ECPG로 작성하다보면 느끼겠지만 몇 가지 단점이 존재한다. ECPG 전처리기는 SQL 구문의 문법을 검사하지 못한다. 그리고 에러코드가 단순해서 좀 더 자세한 에러검사를 하기가 힘들며, 널(null)과 빈 문자열(empty)를 구분하지 못한다. 변수를 주고 받는 과정에서 편리하다고는 하지만 생각만큼 되지 않을 때가 있다. query라는 C 변수에 "select *from pg_database"라는 문자열이 포함되어 있다고 가정하자. exec sql :query; 이 내장 SQL이 다음과 같이 확장되기를 기대한다면 에러가 발생한다. exec sql select *from pg_database; 이게 ECPG 문제인지, 아니면 표준 Embedded SQL의 문제인지, 또는 필자의 희망사항인지는 알지 못한다. 그리고 특정 테이블의 컬럼수를 얻기에도 편리하지 않다. 해당 테이블에 대해 미리 알고 변수를 준비하고 있어야 작업을 할 수 있다. PostgreSQL 6.3에서 지원하는 Embedded SQL이 필자가 보기에는 어느 정도 쓸모가 있다고 본다. 그 이유는 예전의 ECPG 0.x 버전보다는 상당히 향상되었고, 프로그래머에게 편리함을 주고 있기 때문이다. 데이터베이스 프로그래밍을 잘만 기획한다면 ECPG로 libpq를 사용한 소스보다 절반 정도의 분량으로 한껏 편리하게 작업을 할 수 있을 것이다. PostgreSQL도 6.3 버전을 맞아 계속 발전하고 있는 것 같다. 언제 한번 환경이 갖추어지면 PostgreSQL과 전세계적으로 유명한 상용 RDBMS와의 벤치마크를 해보는 것도 유익할 것 같다. PostgreSQL 6.3과 함께 재미있는 리눅스 여행이 되길 바란다. [출처] 공개 데이터베이스 서버 PostgreSQL (6)|작성자 황제펭귄