「hex」書式ではバイナリデータの各バイトを上位4ビット、下位4ビットの順で2桁の16進数に符号化します。 （エスケープ書式と区別するために）文字列全体は\xという並びの後に付けられます。 一部の文脈では、先頭のバックスラッシュを二重にしてエスケープさせる必要があるかもしれません(以下を参照 4.1.2.1)。 これはエスケープ書式でバックスラッシュを二重にしなければならない場合と同じで、詳細は以下に示します。 入力する16進数の桁は大文字でも小文字でも構いません。 数字のペアの間に空白文字を入れることができます。 （しかし桁の組み合わせの間や先頭の\xの間には入れることはできません。） hex書式は外部のアプリケーションおよびプロトコルの間で広く互換性を持ち、また、エスケープ書式と比べ変換が高速になる傾向があります。 このため使用が好まれます。

例

SELECT '\xDEADBEEF';

「エスケープ」書式はbytea型用の伝統的なPostgreSQLの書式です。 これは、バイナリ列をASCII文字の並びとして表現しASCII文字として表現できないバイトは特殊なエスケープシーケンスとして表現するという方式を取ります。 アプリケーションの見地から文字として表現されたバイトが有意であれば、この表現は簡便です。 しかし現実にはバイナリ列と文字列の間の区別があいまいになりますので、通常は混乱します。 また選択されたこのエスケープ機構自体が多少非効率的です。 このためこの書式はおそらくほとんどの新しいアプリケーションでは避けるべきでしょう。

エスケープ書式でbytea値を入力する際に、特定の値のオクテットをエスケープする必要があります。 なお、すべてのオクテットの値をエスケープすることができます。 一般的にあるオクテットをエスケープするには、それをその3桁の8進数に変換し、バックスラッシュを前に付けます。 他にもバックスラッシュ自体(10進数表記のオクテットで92)を二重のバックスラッシュとして表現することができます。 表 8.7には、エスケープする必要がある文字と、その適用可能な代替エスケープシーケンスを示しています。

実際には、表示できないオクテットに対するエスケープ要求はロケールの設定に依存して異なります。 ロケールの設定によっては、エスケープをしないで済むこともあります。

表 8.7で示したように、シングルクォートが二重に必要な理由は、SQLコマンド中のあらゆる文字列に当てはまるためです。 一般的な文字列パーサは最も外側のシングルクォートを消費し、シングルクォートのペアを一つの文字データに減らします。 byteaを入力する関数が見るのは単に一つのシングルクォートであり、一個の単純なデータ文字として扱います。 しかし、byteaを入力する関数はバックスラッシュを特別なものとして扱い、表 8.7に示されているその他の動作はこの関数で実装されています。

一般的な文字列パーサはバックスラッシュのペアを一つの文字データに減らすため、文脈によってはバックスラッシュは上記に見られるように、重ねる必要があります。 4.1.2.1も参照ください。

Byteaオクテットはデフォルトではhex書式で出力されます。 bytea_outputをescapeに変えると、「表示できない」オクテットは先頭にバックスラッシュがついた3桁のオクテットの値に変換されます。 ほとんどの「表示可能な」オクテットはクライアント文字セットの標準的な表示で出力されます。例:

SET bytea_output = 'escape';

SELECT 'abc \153\154\155 \052\251\124'::bytea;
     bytea
----------------
 abc klm *\251T

10進数で92(バックスラッシュ)を持つオクテットは出力時に二重になります。 詳細は表 8.8を参照してください。

使用するPostgreSQLのフロントエンドによっては、bytea文字列をエスケープまたはアンエスケープする追加的な作業が必要になることがあります。 例えば、使用するインタフェースが改行文字や復帰文字を自動的に翻訳してしまう場合、これらの文字もエスケープしなければならないかもしれません。