startup_cbコールバックは、モジュールのロード直後に実行されます。 このコールバックは、ローカルの状態を設定し、必要に応じて追加の初期設定を実行するために使用できます。 検証器モジュールに状態がある場合は、state->private_dataを使用してそれを格納できます。

typedef void (*ValidatorStartupCB) (ValidatorModuleState *state);

validate_cbコールバックは、ユーザがOAuthを使用して認証しようとするときに、OAuth交換中に実行されます。 以前の呼び出しで設定された状態は、state->private_dataで使用できます。

typedef bool (*ValidatorValidateCB) (const ValidatorModuleState *state,
                                     const char *token, const char *role,
                                     ValidatorModuleResult *result);

トークンには、検証対象のベアラトークンが含まれます。 PostgreSQLは、トークンが構文的に整形式であることを確認していますが、他のバリデーションは実行されていません。 ロールには、ユーザがログインとして要求したロールが含まれます。 コールバックはresult構造体に出力パラメータを設定する必要があり、これは次のように定義されます。

typedef struct ValidatorModuleResult
{
    bool        authorized;
    char       *authn_id;
} ValidatorModuleResult;

モジュールがresult->authorizedをtrueに設定した場合のみ、コネクションが続行されます。 ユーザを認証するために、認証されたユーザ名（トークンを使用して決定されたもの）はpallocされ、result->authn_idフィールドで返される必要があります。 または、result->authn_idトークンが有効であるが、関連付けられたユーザIDを決定できない場合は、NULLに設定される場合があります。

検証器は、内部エラーを示すためにfalseを返すことができ、この場合、すべての結果パラメータが無視され、接続は失敗します。 そうでない場合、検証器はtrueを返して、トークンを処理し、認可決定を行ったことを示す必要があります。

validate_cbが返された後の動作は、特定のHBA設定によって異なります。 通常、result->authn_idユーザ名は、ユーザがログインしようとしているロールと正確に一致する必要があります。 （この振る舞いはユーザマップで変更できます。） しかし、delegate_ident_mappingが有効なHBAルールに対して認証する場合、PostgreSQLはresult->authn_idの値をまったくチェックしません。この場合、トークンが指示されたroleの下でユーザがログインするのに十分な権限を持つかどうかは、検証器に委ねられます。

shutdown_cbコールバックは、接続に関連付けられたバックエンドプロセスが終了するときに実行されます。 検証器モジュールにメモリを割り当てられた状態がある場合、このコールバックはリソースリークを回避するためにフリーする必要があります。

typedef void (*ValidatorShutdownCB) (ValidatorModuleState *state);