Re: Typo in "43.9.1. Reporting Errors and Messages"?

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Euler Taveira <euler(at)eulerto(dot)com>
Cc: eric(dot)mutta(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Typo in "43.9.1. Reporting Errors and Messages"?
Date: 2023-10-31 18:00:00
Message-ID: 8247bd59-6c9d-b56b-94f0-6e01993473cd@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

Hi Bruce,

31.10.2023 17:52, Bruce Momjian wrote:
>
>> It is referring to the internal constant (see src/backend/utils/errcodes.h). It
>> was like you are proposing and it was changed in
>> 66bde49d96a9ddacc49dcbdf1b47b5bd6e31ead5. Reading the original thread, there is
>> no explanation why it was changed. Refer to internal names is not good for a
>> user-oriented text. I think it would be better to use the condition name (in
>> lowercase) like it is referred to in [1]. I mean, change
>> ERRCODE_RAISE_EXCEPTION to raise_exception.
>>
>> [1] https://www.postgresql.org/docs/current/errcodes-appendix.html
> Alexander, Michael, can you explain why this commit removed ERRCODE_:
>
> commit 66bde49d96

I don't remember details, but I think the primary reason for the change
was that "RAISE_EXCEPTION" occurred in the whole tree only once (before
66bde49d96). Now I see, that I had chosen the wrong replacement — I agree
with Euler, change to "raise_exception" would be more appropriate.

(I've found a similar mention of ERRCODE_xxx in btree.sgml:
  Before doing so, the function should check the sign
  of <replaceable>offset</replaceable>: if it is less than zero, raise
  error <literal>ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE</literal> (22013)
  with error text like <quote>invalid preceding or following size in window
  function</quote>.
but I think that's okay here, because that identifier supposed to be used
as-is in ereport/elog.)

Best regards,
Alexander

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Michael Paquier 2023-11-01 00:18:47 Re: Typo in "43.9.1. Reporting Errors and Messages"?
Previous Message Bruce Momjian 2023-10-31 17:20:09 Re: doc-fix-for-POSIX-Time-Zone-Specifications

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2023-10-31 18:12:17 Re: Document efficient self-joins / UPDATE LIMIT techniques.
Previous Message Tom Lane 2023-10-31 17:58:34 Re: Question about non-blocking mode in libpq