SQLにおける文字列定数は、単一引用符（'）で括られた任意の文字の並びです。 例えば、'This is a string'です。 文字列定数内に単一引用符を含めるには、2つ続けて単一引用符を記述します。 例えば、'Dianne''s horse'です。 二重引用符(")とは同一ではない点に注意してください。

2つの文字列定数が、少なくとも1つの改行を含んだ空白のみで区切られている場合は、2つの定数は連結され、実質的に1つの定数として書かれたように処理されます。 例を示します。

SELECT 'foo'
'bar';

は、

SELECT 'foobar';

と同じです。しかし、

SELECT 'foo'      'bar';

は有効な構文ではありません （このちょっとした奇妙な振舞いはSQLで決められているもので、PostgreSQLではこの標準に従っています）。

PostgreSQLでは、また、「エスケープ」文字列定数を受け付けます。 これは標準SQLの拡張です。 エスケープ文字列定数は、E(大文字でも小文字でもかまいません)を開始単一引用符の直前に記述することで指定されます。 例えばE'foo'です。 （複数行に渡るエスケープ文字列定数では、最初の開始引用符の前にのみEを記述してください。） エスケープ文字列の中では、バックスラッシュ文字（\）によりC言語のようなバックスラッシュシーケンスが開始し、その中でバックスラッシュとそれに続く文字の組み合わせが（表 4.1で示したように）特別なバイト値を表現します。

バックスラッシュの後のそのほかの全ての文字はそのまま扱われます。 従って、バックスラッシュ文字を含ませるときは２つのバックスラッシュ（\\）を記載します。 同時に、エスケープ文字列の中では、単一引用符を、通常の方法の''に加え、\'としても含めることができます。

特に8進数や16進数エスケープを用いて作成されるバイトシーケンスが、サーバ文字セット符号化方式において有効な文字で構成されていることはコードを書く人の責任です。 便利な代替手段は、Unicodeエスケープか、4.1.2.3で説明するもう一つのUnicodeエスケープ構文を代わりとして使用することです。そうすればサーバが文字変換が可能か検査するでしょう。

コードゼロの文字は文字列定数の中に入れられません。

PostgreSQLは同時に、文字コード番号で任意のUnicode文字を指定可能な文字列に対するもう一つのエスケープ構文を提供します。 Unicodeエスケープ文字列定数は、U&（大文字・小文字のUの後にアンパサンド）で始まり、その直後に、空白を間にはさまず、開始引用符が続きます。 例えば、U&'foo'となります。 （これにより演算子&との曖昧性が生じることに注意してください。 この問題を回避するには空白を演算子の前後に入れます。） 引用符の中で、Unicode文字はバックスラッシュとそれに続く４桁１６進数の文字コード番号で、またはもう１つの方法として、バックスラッシュに続いてプラス符号、そして続いた６桁１６進数の文字コード番号によりエスケープ形式で指定されます。 例えば、文字列'data'は次のように書かれます。

U&'d\0061t\+000061'

次の少し意味のある例はロシア語の「slon」（象）をキリル文字で書いたものです。

U&'\0441\043B\043E\043D'

バックスラッシュ以外のエスケープ文字を使用したい場合、文字列の後にUESCAPE句を使用して指定することが可能です。例をあげます。

U&'d!0061t!+000061' UESCAPE '!'

エスケープ文字には、16進表記用の文字、プラス記号、単一引用符、二重引用符、空白文字以外の任意の単一文字を使用することができます。

識別子内にエスケープ文字をそのまま含めるためには、それを2つ記述してください。

U+FFFFより大きなコードポイントを持つ文字を構成するUTF-16サロゲートペアを指定するために、4桁と6桁の形式のどちらかを使用できますが、技術的には6桁形式の機能によりこれは不要になります。 （サロゲートペアは直接格納されるわけではなく、一つのコードポイントに結合されます。）

サーバ符号化方式がUTF-8でない場合、このエスケープシーケンスの1つで指定されたUnicodeコードポイントは実際のサーバ符号化方式へと変換されます。それが可能でない場合にはエラーが報告されます。

また、文字列定数に対するユニコードエスケープ構文は設定パラメータstandard_conforming_stringsが有効なときのみ動作します。 そうでないとこの構文は、SQL文を構文解釈するクライアントを混乱させ、SQLインジェクションや、それに類似したセキュリティ問題に繋がることさえあるからです。 パラメータがoffに設定されていれば、この構文はエラーメッセージを出して拒絶されます。

文字列定数の標準の構文はたいていの場合便利ですが、対象とする文字列内に多くの単一引用符やバックスラッシュがあると、それらを全て二重にしなければなりませんので理解しづらくなります。 こうした状況においても問い合わせの可読性をより高めるためにPostgreSQLは、「ドル引用符付け」という他の文字列定数の指定方法を提供します。 ドル引用符付けされた文字列定数は、ドル記号（$）、省略可能な0個以上の文字からなる「タグ」、ドル記号、文字列定数を構成する任意の文字の並び、ドル記号、この引用符付けの始めに指定したものと同じタグ、ドル記号から構成されます。 例えば、「Dianne's horse」という文字列をドル引用符付けを使用して指定する方法を、以下に2つ示します。

$$Dianne's horse$$
$SomeTag$Dianne's horse$SomeTag$

ドル引用符付けされた文字列の内側では、単一引用符をエスケープすることなく使用できることを理解して下さい。 実際には、ドル引用符付けされた文字列の内側の文字はまったくエスケープが必要なく、文字列定数はすべてそのまま記述することができます。 その並びが開始タグに一致しない限り、バックスラッシュもドル記号も特別なものではありません。

各入れ子レベルに異なるタグを付けることで、ドル引用符付けされた文字列を入れ子にすることができます。 これは、関数定義を作成する時に非常によく使用されます。 以下に例を示します。

$function$
BEGIN
    RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$

ここで、$q$[\t\r\n\v\\]$q$は、ドル引用符付けされた[\t\r\n\v\\]リテラル文字列を表し、PostgreSQLがこの関数本体を実行する時に認識されます。 しかし、この並びは、外側のドル引用符用の区切り文字$function$に一致しませんので、外側の文字列を対象としている場合は単なる文字の並びとなります。

もしあれば、ドル引用符付けされた文字列のタグは、引用符付けされていない識別子と同じ規則に従います。 ただし、タグにはドル記号を含めることはできません。 タグは大文字小文字を区別します。 したがって、$tag$String content$tag$は正しいのですが、$TAG$String content$tag$は間違いです。

キーワードや識別子の後にドル引用符付けされた文字列を続ける場合は、空白でそれを区切らなければなりません。 さもないと、ドル引用符の区切り文字は、直前の識別子の一部として解釈されます。

ドル引用符付けは、標準SQLで定義されていません。 しかし、複雑な文字列リテラルを記述する場合は標準準拠の単一引用符構文よりも便利なことがよくあります。 特に、他の定数の内部に文字列定数を記述するような場合は役に立ちます。 こうした状況は手続き関数の定義でよく必要とされます。 単一引用符構文では、上の例のバックスラッシュはそれぞれ、4個のバックスラッシュで記述しなければなりません。 この4つのバックスラッシュは、元の文字列定数を解析する際に2つに減少され、そして、関数を実行する際に内部の文字列定数が再解析され1つに減少します。

ビット文字列定数はB（大文字もしくは小文字）が始まりの引用符の前に付いている（間に空白はありません）通常の文字列定数のように見えます。 例えばB'1001'のようになります。 ビット文字列定数の中で許可される文字は0と1のみです。

その他にも、ビット文字列定数はX'1FF'といった具合に、先頭にX（大文字または小文字）を使用して16進表記で指定することもできます。 この表記は、各16進数値をそれぞれ4つの2進数値に置き換えたビット文字列定数と同等です。

どちらの形式のビット文字列定数でも、通常の文字列定数と同じように複数行にわたって続けて書くことができます。 ドル引用符付けはビット文字列定数では使用できません。

数値定数は下記の一般的な形で受け付けられます。

digits
digits.[digits][e[+-]digits]
[digits].digits[e[+-]digits]
digitse[+-]digits

ここでdigitsは1つ以上の10進数字（0〜9）です。 小数点を使用する場合は、少なくとも1つの数字が小数点の前か後になくてはなりません。 指数記号eの付く形式を使う場合にはeの後に少なくとも1つの数字がなければいけません。 空白や他の文字は、定数の中に埋め込むことはできません。 プラスまたはマイナスの符号を先頭につけても、定数の一部とはみなされないことに注意してください。 これらの符号は定数に適用される演算子とみなされます。

下記は有効な数値定数のいくつかの例です。

小数点も指数も含まない数値定数の場合、まずその値がinteger型（32ビット）に収まればinteger型であるとみなされます。 そうでない場合、bigint型（64ビット）で収まればbigint型とみなされます。 どちらでもない場合は、numeric型とみなされます。 定数が小数点または指数あるいはその両方を含む場合は、常に最初にnumeric型であるとみなされます。

数値定数に最初に割り振られるデータ型は、型解決アルゴリズムの開始点に過ぎません。 ほとんどの場合、定数は文脈に基づいて自動的に最も適切な型に変換されます。 必要であれば、特定のデータ型にキャストして、数値がそのデータ型として解釈されるように強制することができます。 例えば、以下のようにして数値をreal型（float4）として処理することができます。

REAL '1.23'  -- 文字列書式
1.23::REAL   -- （歴史的な）PostgreSQL書式

実のところ、これらは以下で説明する一般的なキャスト記法の特別な場合です。

任意の型の定数は下記の表記のいずれかを使って入力することができます。

type 'string'
'string'::type
CAST ( 'string' AS type )

文字列定数のテキストはtypeと呼ばれる型の入力変換ルーチンへと渡されます。 結果は指示された型の定数です。 明示的な型キャストは、定数がどの型でなければならないかについて曖昧な点がなければ（例えば定数が直接テーブル列に代入されている場合）省略しても構いません。 その場合自動的に型強制されます。

文字列定数は通常のSQL記法でもドル引用符付けでも記述することができます。

関数のような構文を使って型強制を指定することも可能です。

typename ( 'string' )

しかし、全ての型の名前でこの方法は使用できるというわけではありません。 詳細は4.2.9を参照してください。

::、CAST()や関数呼び出し構文は、4.2.9で説明する通り、任意の式の実行時の型変換を指定するために使うこともできます。 構文的なあいまいさをなくすために、type 'string'という形式は単なるリテラル定数を指定する場合にのみ使うことができます。 この他type 'string'構文には、配列型では動作しないという制限があります。 配列型の定数の型を指定する場合は::かCAST()を使用してください。

CAST()構文はSQLに従っています。 type 'string'構文は、標準を一般化したものです。 SQLでは、この構文を数個のデータ型でのみ規定しています。 しかし、PostgreSQLではすべての型で使用することができます。 ::付きの構文は、歴史的にPostgreSQLで使用されてきました。 関数呼び出し構文も同じく歴史的に使用されているものです。