마지막으로 고친 날짜: 1998년 5월 25일
영문판을
관리하는 사람: Bruce Momjian (
maillist@candle.pha.pa.us)
한글판을 관리하는 사람: 정직한 (honest@hitel.net)
이 문서의 가장 최신판은 PostgreSQL 웹사이트, http://postgreSQL.org 에서 찾을 수 있습니다.
정규 FAQ 에 언급된 사용자를 위한 문서를 제외하고, 개발자를 위한 도구들이 몇몇 준비되어 있습니다. 첫번째로, /tools 디렉토리의 모든 파일들은 개발자들을 위한 것입니다.
RELEASE_CHANGES 매 릴리즈마다 바뀐 사항들 SQL_keywords SQL'92 표준 키워드 backend 백엔드 디렉토리의 흐름도 ccsym 컴파일러들에 의해 만들어지는 표준 define 문 찾기 entab 탭문자를 공백문자로 바꾸기. pgindent 가 사용함 find_static static 으로 만들어질 수 있는 함수 찾기 find_typedef 소스코드에서 typedef 찾기 make_ctags 각 디렉토리에 vi 용 'tags' 파일 만들기 make_diff *.orig 와 소스의 차이점 만들기 make_etags emacs 용 'etags' 파일 만들기 make_keywords.README 제공되는 예약어들과 SQL'92 의 예약어 비교 make_mkid mkid ID 파일 만들기 mkldexport AIX 익스포트 파일 만들기 pgindent C 소스파일 들여쓰기몇가지만 언급하겠습니다. 브라우저로 tools/backend 디렉토리를 열어보면 흐름도상에 모든 백엔드 컴포넌트가 나타나는 것을 볼 수 있을 것입니다. 아무거나 클릭하면 그에 대한 설명을 볼 수 있습니다. 그리고 나서 디렉토리이름을 클릭하면 소스디렉토리로 가게 될 것이고 실제 소스코드를 불러올 수 있습니다. 소스디렉토리에 있는 README 파일에는 해당모듈의 함수에 대한 설명이 들어 있습니다. 디렉토리에 들어가면 브라우저가 README 파일을 보여줄 것입니다. tools/backend 디렉토리는 PostgreSQL 웹페이지에도 Backend Flowchard 라는 제목으로 들어있습니다.
두번째로, 태그를 처리할 수 있는 편집기가 반드시 있어야 합니다. 그래야 함수호출을 태그처리하여 함수의 정의를 볼 수 있고, 그 함수 안에 또 태그 처리를 하여 더 저수준의 함수를 볼 수 있으며 뒤로 두 번 돌아가 원래의 함수를 볼 수 있게 됩니다. 대개의 편집기들이 tags 나 etags 파일을 사용하여 이 기능을 지원합니다.
세번째로, ftp.postgresql.org 에서 mkid 를 구해야 합니다. tools/make+mkid 를 실행하면 소스의 심볼들을 추출하여 별도의 파일로 만들어주고, grep 이나 편집기를 사용하여 쉽게 이것을 참조해 볼 수 있습니다.
make_diff 에는 배포판에 들어갈 수 있도록 패치용 diff 파일을 만들어주는 도구가 들어있습니다.
pgindent 는 소스파일을 공백문자 넷으로 이루어진 탭을 사용하는 PostgreSQL 의 표준형식으로, 그리고 사용자의 운영체제에 있는 indent 유틸리티가 사용하는 들여쓰기 형식으로 포맷해 줍니다.
두 권의 책을 추천합니다. An Introduction to Database Systems, by C.J. Date, Addison, Wesley 와 A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley 입니다.
palloc() 과 pfree() 는 malloc() 과 free() 대신 사용됩니다. 이것은 PostgreSQL이 트랜잭션이 끝날 때마다 할당된 메모리를 모두 해제시키기 때문입니다. palloc() 과 pfree() 를 사용하면 한 곳에서 할당되고 한참 후에 다른 곳에서 해제된 메모리가 해제되었다는 것을 확실하게 알 수 있습니다. 문맥상으로 보아 어떤 곳에서는 메모리가 할당될 수 있는 경우가 있으며 할당된 메모리가 백엔드에 의해 자동적으로 해제될 때를 제어할 수 있습니다.
백엔드에게 자료를 넘겨줄 때 유연성이 있으면서도 일관된 방법을 사용할 수 있기 때문입니다. 모든 노드는 그 노드 안에 어떤 형태의 자료를 가지고 있는지 명시해주는 NodeTag 를 가집니다. Lists 는 Nodes 의 목록입니다. lfirst(), lnext(), 와 foreach() 를 사용하여 목록을 얻고,
소스코드는 대략 250,000 라인 정도 됩니다. 많은 문제들과 기능들이 코드의 특정한 한 부분에 고립되어 있습니다. 다른 것들은 소스코드에 대한 상당한 지식을 필요로 합니다. 어디에서부터 시작해야할지 모르겠다면 해커리스트에 질문하세요. 그러면 문제의 복잡성과 어디에서부터 시작해야 하는지를 알려줄 겁니다.
또 한가지 염두에 두어야 할 것은 많은 수정사항과 기능들이 매우 적은 코드만을 사용하여 추가될 수 있다는 점입니다. 필자의 경험에 의하면 종종 일을 시작하면서 코드를 추가하게 되는데, 얼마 후 다른 부분을 들여다 보다가 비슷한 일을 누군가 해놓았다는 것을 알게 되고 일을 끝낼때 쯤이면 패치할 내용은 아주 작고 컴팩트 해집니다.
코드를 추가할 때면, 성능과 단순함을 위해 이미 소스에 존재하고 있는 기능을 이용해야 한다는 것을 명심하십시오. 이미 존재하고 있는코드 중 비슷한 일을 하는 코드를 면서 를 살펴보면 많은 도움이 될 것입니다.
소스트리를 얻을 수 있는 방법이 몇 가지 있습니다. 가끔씩 참여하는 개발자들은 그냥 ftp.postgresql.org 에서 가장 최근의 소스 트리를 가져오면 됩니다. 정규 개발자들이라면 역시 ftp.postgresql.org 에서 구할 수 있는 CVSup 를 설치하세요. CVSup 를 사용하면 소스트리를 다운로드하고, 때때로 소스 트리에 변경된 사항을 업데이트해 줍니다. 전체 소스 트리를 매번 다운로드할 필요가 없고, 변경된 파일만 가져오면 됩니다. CVSup 는 개발자들이 소스 트리를 업데이트하지 못하게 막습니다.
소스 트리를 업데이트하려면 두 가지 방법이 있습니다. 앞서 언급된 대로 make_diff 도구를 사용하여 현재 소스 트리에 대한 패치를 생성한 후 이것을 패치 리스트에 보낼 수도 있습니다. 이것은 검토가 이루어진 후에 적절한 시기에 적용될 것입니다. 패치가 꽤 큰 것이라면, 그리고 우리가 베타테스트 중이라면 개발자들은 최종 릴리즈가 나올 때까지 기다려 패치를 적용시키는 편이 좋을 것입니다.
핵심 개발자들에게는 마크(Marc scrappy@postgresql.org) 가 postgresql.org 에 계정을 발급해 줄 것입니다. 그러면 개발자는 자신의 파일을 계정에 ftp 로 올려놓고 패치한 다음, 변경된 사항을 cvs 를 이용해 바로 소스 트리에 반영시킬 수 있습니다.
먼저 psql 를 사용하여 생각했던 대로 동작하는지 확인하세요. 그리고 src/test/regress 를 실행시키고 변경시키기 전과 후의 결과를 src/test/regress/checkresults 로 확인해 보세요. 패치가 회귀 테스트의 결과를 엉뚱하게 바꾸어 놓지는 않았는지 확인해야 합니다. 이렇게 하는 쪽이 힘든 일을 많이 줄여줍니다. 회귀 테스트는 개발자가 미처 고려하지 못할만한 방법들로 코드를 테스트하기 때문에 패치의 많은 버그들을 잡아줍니다. 문제점을 찾아냈다면 나중에 일이 엉망으로 되고 난 후에 해야할 많은 양의 디버깅을 절약할 수 있게 됩니다. 일이 언제 엉망이 될 지는 아무도 알 수 없는 일이지요.
구조체는 parser, rewrite, optimizer, executor 를 거치면서 상당히 많은 지원을 받아야 합니다. 대부분의 구조체들은 src/backend/nodes 에 지원하는 루틴을 가지고 있어 해당 구조체를 만들고, 복사하고, 읽고, 출력하는데 사용합니다. 새로운 필드에 대한 지원을 이 파일에 추가했는지 확인하세요. 새로운 필드를 사용하기 위해 더 필요한 코드들이 없는지 확인하세요. 앞서 언급된 mkid 가 도움이 될 것입니다.