Re: Proposal: Include CHECK constraint expression in violation error DETAIL

Hi Yash,

Thank you for reviewing the patch.

> For clients: any role can read CHECK expressions from, including for
> tables it has no privileges on, so printing the expression doesn't
> seem to expose anything new.
>
> For the server log: an error entry already contains the table, column
> and constraint names, so expression looks less sensitive compared to
> them.
>
> Anything I should improve on?

I agree that no additional security control seems necessary.

When the user has sufficient privileges to display the failing row, the client receives:

ERROR: new row for relation "check_detail_test" violates check constraint "age_check"
DETAIL: Failing row contains (15). Check constraint expression: (age >= 18).

When the user does not have sufficient privileges to display the failing row,
ExecBuildSlotValueDescription() returns NULL. The existing
"val_desc ? ... : 0" check then omits the entire DETAIL message:

ERROR: new row for relation "check_detail_test" violates check constraint "age_check"

The same applies to the server log because the DETAIL field is constructed by
the same code. Therefore, the CHECK expression is not sent to the client or
written to the server log when the failing row detail is suppressed.

I am preparing regression test fixes and will send an updated patch when they are
ready.

Regards,
Koshino

Taiki Koshino<koshino(at)sraoss(dot)co(dot)jp>
SRA OSS K.K.
TEL: 03-5979-2701 FAX: 03-5979-2702
URL: https://www.sraoss.co.jp/

________________________________
差出人: Yash Jadhav <yash(dot)jadhav8008(at)gmail(dot)com>
送信日時: 2026年10月30日 4:23
宛先: Koshino Taiki <koshino(at)sraoss(dot)co(dot)jp>
CC: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>; Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
件名: Re: Proposal: Include CHECK constraint expression in violation error DETAIL

Hi,

I went through the patch and have a few thoughts on the security question.

> Is there a reason why the expression is not included in the error detail?
> (For example, having such information appear in logs could pose a
> security risk.)

For clients: any role can read CHECK expressions from, including for
tables it has no privileges on, so printing the expression doesn't
seem to expose anything new.

For the server log: an error entry already contains the table, column
and constraint names, so expression looks less sensitive compared to
them.

Anything I should improve on?

Regards,
Yash