Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tuiMD-00Axn4-PD for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 01:36:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tuiMC-009bgR-Cc for pgsql-hackers@arkaria.postgresql.org; Wed, 19 Mar 2025 01:36:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tuiMB-009bgJ-VG for pgsql-hackers@lists.postgresql.org; Wed, 19 Mar 2025 01:36:32 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tuiM9-003bjK-2y for pgsql-hackers@postgresql.org; Wed, 19 Mar 2025 01:36:31 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-2c2b7111bb1so3159314fac.3 for ; Tue, 18 Mar 2025 18:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742348189; x=1742952989; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AbDZICtrWiUNcMxo5OdSz29HIaMmAkJfuEfGHqxQwuA=; b=OAaXYwUc76ujYEPJUa+trM7mHGeTZSo9RfXSjhzfEviVdxfzz8lGGp+n1BDGI6kRNH XD4TRAVJt3GNj/p1950VCij7meod7e4WN9HyOBkuPZfWMTKjkrF5Hfxd7R2TSld0vTkM FSHQJ9AIvOLSTGJzG+X5JdRaS1s4jOCpBlkpOLx07j8gbBSwgvbS/Rc79oCNHdMn3kUC botGPWxwNZPqhT3uNnJaUSCrRF0H1rwEqAdj3/KnxDStMUyLiuhIArkcHwcL2IG6Xe+a 6bDrZizK0LzxWlwEnnxQnyn6bC8LLxH/Kdk2RzZTOqWfN+5yyAD/oA7kKoagO6XvOY1L Otmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742348189; x=1742952989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AbDZICtrWiUNcMxo5OdSz29HIaMmAkJfuEfGHqxQwuA=; b=SuLMsOrqnFCpf2WoG1okwPiyjarh3BlB7NRB8m5ul1/jM2QHl0DdUpn3FTYbWmHBLU RI7QNlXNWxKMgCmy8zLDMLvyXzHDr1s/hJKI3O01Ee5jtEH5Eiu/Trm9jcllKJXPF4WJ B2Iztm5s3VvP7Wb0/wQfJdNaxIyItUu7+e7gbetU4VH0QNztqw7iP1ieDDRTXdFS4Vtp MG5swCLP4yFNGlU4usMpZQR+ghUHDzwtTspBaVPHGa2PZ4C+xoJR5XwhKj2QMrzvA3pp ADjmBlP+lnuq6X/dVUT/20ypWvs3FY9xEUJNW1ZHl2kZyfcYgSmYRu8qBlOp9ysbS8T0 vXSw== X-Gm-Message-State: AOJu0YzEc2ynGThLp9A5mqYJE3iuM0P72Qv4UBxUrU6oeLkQ0MOVA0Dl dT+7ugtO9hupVvOh0ndT+/mTTsGrUz/YmVQn8T/s6eIVEL+hQEdQldpsFrlnxk+3XrShO4+Itg1 dvMCkS4zABMeNlIloQJJjBN+lhTs= X-Gm-Gg: ASbGncuATWjV4IypOZhL6qvFb6BGf2In7M/HvBDNERzmfXqOkv687WXtDNd5z9rIVIr MMpai0Luw2FiJdgJvWg7SMEjWPWMoi9s0QX9QPJN9sjaMU3uxwhSgQXdfufgWSrgOTz3wOmDWX+ tDehnfI1Qc2bD9eXrM0pskTYoN X-Google-Smtp-Source: AGHT+IEkn+3AERP/WLukz8hlISfYVrpG2ffjLeMf9j8VPPByG3mpVQJRLJZixEfda8d+ZkeAt72sHE+2iQTgRuVv7rU= X-Received: by 2002:a05:6870:3929:b0:296:e698:3227 with SMTP id 586e51a60fabf-2c74579dc23mr567514fac.36.1742348189349; Tue, 18 Mar 2025 18:36:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Tue, 18 Mar 2025 18:35:52 -0700 X-Gm-Features: AQ5f1Jp53OS_VXIQ3_4fHkTrQf7LoOuDPLZlVd9D3DQlndXY_noewqbuwMAv9YM Message-ID: Subject: Re: add function argument name to substring and substr To: jian he Cc: PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000e6bd5d0630a80c07" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e6bd5d0630a80c07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2025 at 6:20=E2=80=AFPM jian he wrote: > On Wed, Mar 19, 2025 at 8:19=E2=80=AFAM David G. Johnston > wrote: > > > > The vast majority of examples throughout the manual use traditional > function call syntax func_name(arg1, arg2, etc.); I'd rather keep with > convention than start to scatter about alternative syntax choices just to > give the random reader who happens upon this fairly esoteric part of the > manual the benefit of seeing their options. If that is a goal, then I'd > suggest spending some time in our Tutorial adding some more examples with > these alternative forms to people looking to be exposed to new things in > the place they'd go to look for them. They probably won't learn about th= em > from the Syntax section. > > > > On the plus side, I agree now we should add: > > substring(string text, pattern text[, escape-character text]) > > to Table 9.10 > > > in Table Table 9.9 we have > ``` > substring ( string text FROM pattern text ) =E2=86=92 text > Extracts the first substring matching POSIX regular expression; see > Section 9.7.3. > substring('Thomas' from '...$') =E2=86=92 mas > ``` > > can we change to > substring ( string text FROM pattern text ) =E2=86=92 text > substring ( string text, pattern text ) =E2=86=92 text > Extracts the first substring matching POSIX regular expression; > the second format is not standardized. see Section 9.7.3. > substring('Thomas' from '...$') =E2=86=92 mas > > No, based on the (I presume) fact that the substring(string, pattern) variant is not defined in the SQL standard and Table 9.9 is reserved for those functions. It would be a different, but probably worth considering, patch to simply combine Tables 9.9 and 9.10 and just denote which entries are standard and which are not. The decision to split the tables along that property came well before our current table format which seems much more amenable to merging them together. > if we add to > ``substring ( string text, pattern text ) =E2=86=92 text`` > Table 9.10, > then maybe it feels like duplication? > (same function in Table 9.9, Table 9.10, then we also need some words > saying that they are the same) > We can/should add substring(string, pattern) to Table 9.10 for the same reason and the same general wording that substr(string, start) exists on that table. I would be in favor of adding a similar "same as" comment to the functions in Table 9.9 I just now processed the cross references in Table 9.9 to the POSIX section. The new entry in Table 9.10 would want that too. David J. --000000000000e6bd5d0630a80c07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 18, 2025 at 6:20=E2=80=AFPM jian he <jian.universality@gmail.com>= ; wrote:
On Wed, Mar 19, 2025 at = 8:19=E2=80=AFAM David G. Johnston
<david.g= .johnston@gmail.com> wrote:
>
> The vast majority of examples throughout the manual use traditional fu= nction call syntax=C2=A0 func_name(arg1, arg2, etc.);=C2=A0 I'd rather = keep with convention than start to scatter about alternative syntax choices= just to give the random reader who happens upon this fairly esoteric part = of the manual the benefit of seeing their options.=C2=A0 If that is a goal,= then I'd suggest spending some time in our Tutorial adding some more e= xamples with these alternative forms to people looking to be exposed to new= things in the place they'd go to look for them.=C2=A0 They probably wo= n't learn about them from the Syntax section.
>
> On the plus side, I agree now we should add:
> substring(string text, pattern text[, escape-character text])
> to Table 9.10
>
in Table Table 9.9 we have
```
substring ( string text FROM pattern text ) =E2=86=92 text
Extracts the first substring matching POSIX regular expression; see
Section 9.7.3.
substring('Thomas' from '...$') =E2=86=92 mas
```

can we change to
substring ( string text FROM pattern text ) =E2=86=92 text
substring ( string text, pattern text ) =E2=86=92 text
Extracts the first substring matching POSIX regular expression;
the second format is not standardized. see Section 9.7.3.
substring('Thomas' from '...$') =E2=86=92 mas


No, based on the (I presume) fact that t= he substring(string, pattern) variant is not defined in the SQL standard an= d Table 9.9 is reserved for those functions.

It woul= d be a different, but probably worth considering, patch to simply combine T= ables 9.9 and 9.10 and just denote which entries are standard and which are= not.=C2=A0 The decision to split the tables along that property came well = before our current table format which seems much more amenable to merging t= hem together.


if we add to
``substring ( string text, pattern text ) =E2=86=92 text``
Table 9.10,
then maybe it feels like duplication?
(same function in Table 9.9, Table 9.10, then we also need some words
saying that they are the same)

We ca= n/should add substring(string, pattern) to Table 9.10 for the same reason a= nd the same general wording that substr(string, start) exists on that table= .

I would be in favor of adding a similar "same a= s" comment to the functions in Table 9.9

I just = now processed the cross references in Table 9.9 to the POSIX section.=C2=A0= The new entry in Table 9.10 would want that too.

Davi= d J.

--000000000000e6bd5d0630a80c07--