도시락 싸서 말릴 정도는 아니지만요.. 마이너 버전이라도 3 정도 올라간 후에 적용하시는 것을 추천합니다. 여기 계시는 다른 분들도 아마 비슷한 생각이실 듯 합니다 -.-;;;

8 버전에 분명 탐나는 기능들이 많지만 하위 호환성이 지켜지고 있으니까 나중에 별 무리 없이 8로 이전할 수 있을 겁니다. 일단 7.4를 쓰시는 것이 -.-;

저는 하루에도 몇번씩 8.0으로 옮겨갈지 말지를 왔다 갔다 합니다. 송곳으로 다리를 찌르면서 마음을 달래는... 단순히 새 버젼이라는 것 뿐 아니라 기업 환경에서 반드시 있어야 하는 기능들이 8.0에 있기에...

제 생각에 유닉스 환경이라면 8.0.3까지 기다릴 필요는 없어 보입니다. 예전에는 베타나 RC 없이 바로 정식 release가 되었고... 그래서 한 두달 지나 x.x.3 정도 되어야 문제 없이 쓸 수 있는 상태가 되곤 했는데 이번에는 계속 test 버젼을 release해 왔기 때문에 심각한 문제는 없을 것 같습니다. 저는 설 지나고 저희 프로젝트에 써보려고 합니다.

현재 dsn 개발시스템 쪽에서는

어제부터 이미 8.0.1 버전으로 바꾸어서 열심히(?) 테스트 해보고 있는데, DSN 환경에서는 문제가 없어보입니다.

워낙 단순한 환경이기 때문에.

성격 급한 분들이 먼저 실무에 도입해 보고 문제점들을 빨리 알려주야  빨리 안정화 될 것 같은데.

늘 그래왔듯이, Major 버전 릴리즈 다음에 꼭 치명적인 버그 한 두개가 발표되거든요. :)

이번에 LOAD 문제 처럼. (News 란에 썼듯이 대부분의 환경에서는 치명적인 문제라고 보기 힘들겠지만, 아무튼 중요한 부분이기는 하니)

이런 치명적인 부분을 찾아내는 가장 좋은 방법은 실무에 사용해보는 것일터인데...

개인적인 판단으로 일단 설연휴를 기점으로 DSN 서비스는 8.0.1 버전으로 돌릴 계획입니다.

일하고 있는 회사에서는 늘 그래왔듯이 봄에 (4-5월즈음에) 바꿀 예정입니다.

참, 이번에 DB 서버 마이그레이션을 계획하신다면, libpq 쓰는 쪽도 변경하시길 바랍니다. libpq 쪽도 별로 안바뀐 것 같더니만 많이 바뀌었더군요. (php 기반이라면 새 libpq를 쓰도록 작업해주십시오, 알아서 잘)

아무튼, 글을 정리하면,

DB를 사용하는 것이 비교적 기본적인 것들이라면, 늘 사용되는 가장 보편적인 것들이라면, 8.0.1 버전 사용하셔도 무방할 듯싶습니다. 기본적이고, 보편적인 기능들에 대한 문제점이 있었다면, 오래전에 보고되었을터이니,

하지만, 새로운 기능을 사용한다거나, 다른 사람들이 잘 안쓰는 독창적인 방법을 사용한다거나 할 경우는 좀 더 여유를 가져보는 것이 좋을 듯싶습니다.

참 오랜만에 와 봅니다.

모든 패키지들이 다 그러하듯이

항상 최신 버젼이 좋은것만은 아닙니다.

그리고 여러 사람들이 이구동성으로 이야기하듯이

마이너버젼 3 정도 될때 실무에 적용하라 라는 말이 있는데

전 다르게 생각합니다. 어쩌면 시간이 많아서이겠지요

대부분은 최신버젼에서 그 이하버젼의 내용을 그대로 담고 있으며,

그보다 더 향상된 기능을 가지고 있습니다. 문제점보완도 그러하겠지요

그러므로 현재 실무에 적용시킨 버젼이 있고 데이타량이 많다면 문제가 조금 틀려지겠지만.(틀려질 문제도 없을거 같습니다. 데이타 백업작업이 귀찮을 뿐..)

전 잘 모르지만 항상 그래왔듯이 메이져버젼이 발표될때 곡 하나이상의 치명적 버그가 존재했다고 합니다.

하지만 이 문제도 그렇게 중요하게 생각안하셔도 될듯 합니다(잉??)

이유는

그 치명적인 버그라는것이 이전버젼에서도 그대로 안고 있거나,

추가된 새로운 기능에서의 버그일것으로 생각되며, 기존의 기능에서는

아니라고 생각되기 때문입니다.(망구 제생각)

그 버그는 이전버젼 사용자에겐 별로 중요치 않다 라는 것이지요

그 버그가 고쳐지기까지는 새로운 기능을 안 쓰면 되니깐..

다시 종합해보면

메이져버젼에서 치명적 버그가 있다 하더라도

그 이전 버젼과 같거나 향상되었다는 것입니다.

절대 그 치명적인 버그가 이전버젼에 같이 존재하거나 없는 기능이기 때문입니다.

그러므로 8.0.1 을 사용하더라도 별 무리 없다는 입장입니다.

최신버젼에 더 빨리 적응할 수 있지않나 생각됩니다.

사용해도 무방하다고 생각되네요.

저도 tyro님과 비슷한 생각인데요.

오라클 같은 DB를 써보면 아시겠지만 버그 엄청 많습니다. 제가 경험한 것도 한두개가 아니구요. 이런 버그를 오라클 본사에 리포트 해서 해결받으려면 엄청난 비용의 유지보수 계약을 별도로 체결 해야 합니다. 그래서 대부분 유지보수 업체에서 말해주는 해결책이라는 것들이 그 버그를 우회하는 방법 정도라고 할까요.

제가 사용 미들웨어나 DBMS 유지보수 업체와 같이 일을 하면서 많이 싸우는 것이 어플리케이션을 다 만들어 놓으면 나중에 한다는 소리가 "그 기능은 문제가 있어서 쓰시면 안되요. 어플리케이션을 고치셔야 하겠네요." 정도 입니다. 영업 사원은 이런 이런 기능 되서 좋다고 하고 나중에 써보면 그 기능은 사실 이런 이런 문제가 있으니 쓰지 말라고 하고...

결국 어플리케이션 개발자는 책임 범위가 단순히 주어진 개발 환경 위에 고객의 요구사항을 구현하는 것을 넘어 개발 환경 자체가 잘 돌아가는지 확인하는 것까지 포함되더군요. 저는 주로 이런 습관을 "방법론적 회의"라고 합니다. 베이컨이 모든 것에 의심을 품었던 것 처럼 저도 OS와 DBMS의 모든 영역에 대해서 의심을 한번 해보는 것이죠. 물론 가장 먼저 의심하는 것은 저 자신입니다만...

말이 벗어난 기분이 들지만... 좌우간... DBMS의 버그라는 것... 꼭 PgSql같은 Open Source에만 발생하는 문제가 아닌 늘 접하는 문제이니 만큼 크게 걱정할 것은 아니라는 점과... 차라리 Open Source이기 때문에 문제를 빨리 해결할 수 있다는 말을 하고 싶었습니다. 문제 생기면 바로 여기에 물어보거나 mailing list에 올려도 되고... 그래도 안되면 직접 고치면 되니까요. 제 생각에는 다른 사용 DB의 버그 때문에 고생하는 정도와 시간, 비용에 비하면 훨씬 덜할 겁니다.