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<[email protected]> SRA OSS K.K. TEL: 03-5979-2701 FAX: 03-5979-2702 URL: https://www.sraoss.co.jp/ ________________________________ 差出人: Yash Jadhav <[email protected]> 送信日時: 2026年10月30日 4:23 宛先: Koshino Taiki <[email protected]> CC: PostgreSQL Hackers <[email protected]>; Yugo Nagata <[email protected]> 件名: 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
