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 1rL9eN-006NUX-P6 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2024 22:23:47 +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 1rL9eM-008PPo-1M for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2024 22:23:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rL9eL-008POg-NX for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2024 22:23:45 +0000 Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rL9eJ-00FOzl-Jk for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2024 22:23:45 +0000 Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-3bb69bfdd96so361407b6e.1 for ; Wed, 03 Jan 2024 14:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704320621; x=1704925421; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=KiwM3g1zk5Nepq5JQpVRHfi92f9dNPNEyMMJ4FhPaMM=; b=HzjO50b5gabImzJFagLpee+13adx7ryr7VLUCflrljV6qXlYhPPDpUox+knbDZcKvH mTiu6CoJdkYel2kkBH+UNP8d3Wc5bOqKlIIV5amll72E8Sf0DiIpOGAixOBO6360VPic roHzaaVTnFbMEfGcDi6hmK12Gw+Gm5lRPBsCzxqBT5n1499hY+cwVT7pD89ax8qFDpHT RmuIoKr3MpoUBBlkyaC0jcmzhqJH6nc2053UUKlVgaU7QJAcCbxdM+ubNo8+NBdJ+XwH c92t1v62iEuVqJaUxlENQG+yM9+w6ARbOpZktoSR94gaUahRHLm3ecc2vqJR6yHc+frM yAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704320621; x=1704925421; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KiwM3g1zk5Nepq5JQpVRHfi92f9dNPNEyMMJ4FhPaMM=; b=srTy/5BKX2RQEbrfwDC6SO3qIucN7r8kYN3v8opFmLmiS8feBe54agARPrT/FoMqiQ CsHCoKbGjPEeucLlDsSoHS6azBpyan6+eh9dzANHHxbm81wrOv/6x9SP1a5pumjAcM5T puOFlEH27MevpupJWZnT80egs4d7UYqDsEgMKmogL3kGp8UHWo1qsAoiFomSCHvdevcS mpOTMzoOU3Lcn5+eRUgUrAIOfV/RbvG7bOOMVazWHdxxb4x+j3Fik5JtmJPf8Hqsj3Vg Qtm8//1JJRxaVJVoBdze1/u15bBlnNLF5DuhO4zSzcqrOGATQ0pDHkKSQflinvfcWiif Gj9g== X-Gm-Message-State: AOJu0YxuAKSZpQp+Bmx3b8bCpa5JjJlMxnKjpO7S+JMN7y4hCNpDb6h2 bbktclQqyyfnZ3zx76ZtKg== X-Google-Smtp-Source: AGHT+IEN6YtxNbnXex4dwSPWoV4BYo9RONO4xYwAfJhUxJhBJIG1ChTI1A+OdU+/s7buHjG1lPhtzQ== X-Received: by 2002:a54:4684:0:b0:3b9:fd05:f124 with SMTP id k4-20020a544684000000b003b9fd05f124mr472974oic.55.1704320621431; Wed, 03 Jan 2024 14:23:41 -0800 (PST) Received: from [192.168.2.9] (070-113-014-216.res.spectrum.com. [70.113.14.216]) by smtp.gmail.com with ESMTPSA id b19-20020aca2213000000b003b274008e46sm3757227oic.0.2024.01.03.14.23.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jan 2024 14:23:41 -0800 (PST) Message-ID: <0eb3a5d7-75d8-4da5-9c88-a93deccdaa03@gmail.com> Date: Wed, 3 Jan 2024 16:23:37 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: add function argument names to regex* functions. Content-Language: en-US To: Dian Fay , jian he , Peter Eisentraut Cc: PostgreSQL Hackers References: From: Jim Nasby In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk
On 1/1/24 12:05 PM, Dian Fay wrote:
I agree that the parameter name `n` is not ideal. For example, in
`regexp_replace` it's easy to misinterpret it as "make up to n
replacements". This has not been a problem when `n` only lives in the
documentation which explains exactly what it does, but that context is
not readily available in code expressing `n => 3`.
Agreed; IMO it's worth diverging from what Oracle has done here.
Another possibility is `index`, which is relatively short and not a
reserved keyword ^1. `position` is not as precise but would avoid the
conceptual overloading of ordinary indices.

I'm not a fan of "index" since that leaves the question of whether it's 0 or 1 based. "Position" is a bit better, but I think Jian's suggestion of "occurance" is best.

--
Jim Nasby, Data Architect, Austin TX