Re: Fix bug of CHECK constraint enforceability recursion

> On Jun 8, 2026, at 22:52, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> On 2026-Jun-08, Chao Li wrote:
>
>>> Keep errmsg() messages on a single line to improve grepability.
> G
>> I’m not sure this needs to be changed. The message is quite long, and
>> there are existing precedents for splitting long errmsg() strings
>> across multiple lines. For example:
>> ```
>> if (getExtensionOfObject(NamespaceRelationId, nspOid) == extensionOid)
>> ereport(ERROR,
>> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>> errmsg("cannot move extension \"%s\" into schema \"%s\" "
>> "because the extension contains the schema",
>> extensionName, newschema)));
>> ```
>>
>> So, this does not seem to be a strict rule. I also don’t think this
>> hurts grepability much in practice, since searching for the
>> distinctive part of the message still finds it.
>
> Personally I find myself upset whenever I come across messages split in
> this way. Kindly do not add more if you can avoid it. It [my dislike
> for that] is not strong enough to create a commit to stitch them back,
> but I frequently do so in my local editor and later discard the change
> when collecting changes to commit via "git add -p".
>
> Greppability is subjective -- you don't know which part is
> "distinctive". For instance, when looking for message
> refactoring/rewording I grep for things such as "cannot.*schema" or
> such, and any arbitrary splitting could potentially thwart that.
>
>
> Lastly, when the message is in a single line, grammatical mistakes are
> easier to see, such as the missing "the" in
> errmsg("cannot mark inherited constraint \"%s\" as NOT ENFORCED because [the] matching constraint on parent table \"%s\" is ENFORCED", ...)
>

Thanks for the explanation. I will treat that as a rule in future when working for PG code. So, noted.

>
> In this case I would also move the NOT ENFORCED clause out of the
> translatable message and replace it with %s; and I'm wondering whether
> the part after "because" should be errdetail or not.

In v10, I split the “because” part to a errdetail, also moved out NOT ENFORCED out of the translate message.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/