모든 의사소통은 메시지 스트림을 통해 이루어집니다. 메시지의 첫 번째 바이트는 메시지 유형을 식별하고 다음 4바이트는 메시지의 나머지 길이를 지정합니다(이 길이 수에는 자체가 포함되지만 메시지 유형 바이트는 포함되지 않음). 메시지의 나머지 내용은 메시지 유형에 따라 결정됩니다. 기록상의 이유로 클라이언트가 보낸 첫 번째 메시지(시작 메시지)에는 초기 메시지 유형 바이트가 없습니다.

메시지 스트림과의 동기화 손실을 방지하기 위해 서버와 클라이언트는 일반적으로 내용을 처리하기 전에 전체 메시지를 버퍼로 읽어들입니다(바이트 수 사용). 이를 통해 컨텐츠 처리 중 오류가 감지된 경우 쉽게 복구할 수 있습니다. 극단적인 상황(예: 메시지를 버퍼링할 메모리가 충분하지 않은 경우)에서 수신자는 바이트 수를 사용하여 메시지 읽기를 재개하기 전에 건너뛸 입력량을 결정할 수 있습니다.

반대로, 서버와 클라이언트 모두 불완전한 메시지를 보내지 않도록 주의해야 합니다. 이는 일반적으로 메시지 전송을 시작하기 전에 전체 메시지를 버퍼에 마샬링하여 수행됩니다. 메시지를 보내거나 받는 도중에 통신 오류가 발생하는 경우 메시지 경계 동기화를 복구할 가능성이 거의 없으므로 유일한 합리적인 대응은 연결을 포기하는 것입니다.

확장 쿼리 프로토콜에서 SQL 명령 실행은 여러 단계로 나누어집니다. 단계 사이에 유지되는 상태는 두 가지 유형의 객체로 표현됩니다.준비된 진술그리고포털. 준비된 문은 텍스트 쿼리 문자열의 구문 분석 및 의미 분석 결과를 나타냅니다. 준비된 문은 그 자체로는 실행할 준비가 되어 있지 않습니다. 왜냐하면 다음과 같은 특정 값이 부족할 수 있기 때문입니다.매개변수. 포털은 누락된 매개변수 값이 채워진 실행 준비가 되었거나 이미 부분적으로 실행된 명령문을 나타냅니다. (For선택문, 포털은 열린 커서와 동일하지만 커서는 비-선택문장.)

전체 실행 주기는 다음으로 구성됩니다.파싱단계, 텍스트 쿼리 문자열에서 준비된 명령문을 생성합니다. 에바인드단계: 준비된 명령문과 필요한 매개변수 값이 제공된 포털을 생성합니다. 그리고실행포털의 쿼리를 실행하는 단계입니다. 행()을 반환하는 쿼리의 경우선택, 표시등), 실행 단계에서는 제한된 수의 행만 가져오도록 지시할 수 있으므로 작업을 완료하려면 여러 실행 단계가 필요할 수 있습니다.

백엔드는 준비된 여러 명령문 및 포털을 추적할 수 있습니다(그러나 이러한 것들은 세션 내에만 존재하며 세션 간에 공유되지 않습니다). 기존의 준비된 명령문 및 포털은 생성 시 할당된 이름으로 참조됩니다. 게다가,“이름 없음”준비된 성명과 포탈이 존재합니다. 이는 명명된 개체와 거의 동일하게 동작하지만 이에 대한 작업은 쿼리를 한 번만 실행한 후 삭제하는 경우에 최적화된 반면 명명된 개체에 대한 작업은 여러 용도에 대한 기대에 최적화되어 있습니다.

특정 데이터 유형의 데이터는 여러 가지 다른 방식으로 전송될 수 있습니다.형식. 현재포스트그레SQL7.4 유일하게 지원되는 형식은 다음과 같습니다.“텍스트”그리고“바이너리”, 그러나 프로토콜은 향후 확장을 제공합니다. 모든 값에 대해 원하는 형식은 다음과 같이 지정됩니다.형식 코드. 클라이언트는 전송된 각 매개변수 값과 쿼리 결과의 각 열에 대한 형식 코드를 지정할 수 있습니다. 텍스트의 형식 코드는 0이고, 바이너리의 형식 코드는 1이며, 다른 모든 형식 코드는 향후 정의를 위해 예약되어 있습니다.

값의 텍스트 표현은 특정 데이터 유형에 대한 입력/출력 변환 함수에 의해 생성되고 허용되는 문자열입니다. 전송된 표현에는 후행 널 문자가 없습니다. 프런트엔드는 수신된 값을 C 문자열로 처리하려면 수신된 값에 1을 추가해야 합니다. (그런데 텍스트 형식은 삽입된 null을 허용하지 않습니다.)

정수에 대한 이진 표현은 네트워크 바이트 순서(가장 중요한 바이트부터)를 사용합니다. 다른 데이터 유형의 경우 이진 표현에 대해 알아보려면 설명서나 소스 코드를 참조하세요. 복잡한 데이터 유형에 대한 이진 표현은 서버 버전에 따라 변경될 수 있다는 점을 명심하세요. 일반적으로 텍스트 형식이 더 이식성이 좋은 선택입니다.