^@ operator vs start_with function
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/functions-string.html Description: https://www.postgresql.org/docs/16/functions-string.html Said text ^@ text → boolean Returns true if the first string starts with the second string (equivalent to the starts_with() function). 'alphabet' ^@ 'alph' → t This is not true equivalent, because ^@ can be accelerated by special SP-GiST index https://www.postgresql.org/docs/14/spgist-builtin-opclasses.html while function starts_with() perhaps no. Thus need to mention in the description of ^@ it can be accelerated by the special index with link to it. And in the description on start_with() need to mention that alternative ^@ is better, because it can be accelerated by index, while the function is not.
Re: 'value' has special behaviour in alter system
On Tue, Oct 24, 2023 at 02:36:14PM -0400, Bruce Momjian wrote: > On Tue, Oct 24, 2023 at 02:05:53PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > I have developed the attached patch to document this. > > > > This seems a little imprecise: > > > > + Values with non-alphanumeric characters must be quoted. > > > > I think accurate is more like "Values that are neither a number > > nor a valid identifier must be quoted." > > > > Also, that para already mentions that the input can be a > > comma-separated list when appropriate, so your add-on para seems > > partially repetitive. I think you could just drop the first > > sentence of it. > > Agreed, updated patch attached. Patch applied to all supported versions. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: Typo in "43.9.1. Reporting Errors and Messages"?
On Tue, Aug 2, 2022 at 09:49:47AM -0300, Euler Taveira wrote: > On Sun, Jul 31, 2022, at 8:37 PM, PG Doc comments form wrote: > > Towards the end of the "43.9.1. Reporting Errors and Messages" section > (here > https://www.postgresql.org/docs/current/plpgsql-errors-and-messages.html# > PLPGSQL-STATEMENTS-RAISE) > we have the following sentence: > > > If no condition name nor SQLSTATE is specified in a RAISE EXCEPTION > command, the default is to use ERRCODE_RAISE_EXCEPTION (P0001). > > Looking at the list of error codes (here > https://www.postgresql.org/docs/current/errcodes-appendix.html) I think > the > "ERRCODE_RAISE_EXCEPTION (P0001)" is a typo and should remove "ERRCODE_" > and > simply read "RAISE_EXCEPTION (P0001)" or perhaps "ERRCODE = > 'RAISE_EXCEPTION'" since that's how the default behaviour would be written > in a RAISE statement. > > 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 Author: Michael Paquier Date: Tue Aug 13 13:53:41 2019 +0900 Fix inconsistencies and typos in the tree, take 10 This addresses some issues with unnecessary code comments, fixes various typos in docs and comments, and removes some orphaned structures and definitions. Author: Alexander Lakhin Discussion: https://postgr.es/m/9aabc775-5494-b372-8bcb-4dfc0bd37...@gmail.com -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: doc-fix-for-POSIX-Time-Zone-Specifications
On Mon, May 17, 2021 at 11:36:34AM +, tanghy.f...@fujitsu.com wrote: > Hi > > Attached a patch to delete "CURRENT(as of 2020) " description in POSIX Time > Zone Specifications. > I'm not a native English speaker, if my fix is not appropriate or > insufficient, please be kind to share your thought with me. I think "the" was missing, so I added it: As an example, CET-1CEST,M3.5.0,M10.5.0/3 describes the current (as of 2020) timekeeping practice in Paris. This specification --- -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
Re: Typo in "43.9.1. Reporting Errors and Messages"?
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 offset: if it is less than zero, raise error ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE (22013) with error text like invalid preceding or following size in window function. but I think that's okay here, because that identifier supposed to be used as-is in ereport/elog.) Best regards, Alexander
Re: Typo in "43.9.1. Reporting Errors and Messages"?
On Tue, Oct 31, 2023 at 09:00:00PM +0300, Alexander Lakhin wrote: > 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. Indeed, it looks like the origin of the confusion is the casing here, so changing to "raise_exception" like in the appendix sounds good to me: https://www.postgresql.org/docs/devel/errcodes-appendix.html So you mean something like the attached then? > (I've found a similar mention of ERRCODE_xxx in btree.sgml: > Before doing so, the function should check the sign > of offset: if it is less than zero, raise > error ERRCODE_INVALID_PRECEDING_OR_FOLLOWING_SIZE (22013) > with error text like invalid preceding or following size in window > function. > but I think that's okay here, because that identifier supposed to be used > as-is in ereport/elog.) Yep, still this one is not that old (0a459cec96d3). -- Michael diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml index 83f867f91d..5977534a62 100644 --- a/doc/src/sgml/plpgsql.sgml +++ b/doc/src/sgml/plpgsql.sgml @@ -3942,7 +3942,7 @@ RAISE unique_violation USING MESSAGE = 'Duplicate user ID: ' || user_id; If no condition name nor SQLSTATE is specified in a RAISE EXCEPTION command, the default is to use -ERRCODE_RAISE_EXCEPTION (P0001). +raise_exception (P0001). If no message text is specified, the default is to use the condition name or SQLSTATE as message text. signature.asc Description: PGP signature
