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 1tBVI0-004HFi-C9 for pgsql-docs@arkaria.postgresql.org; Thu, 14 Nov 2024 08:33:19 +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 1tBVHx-0023w9-RA for pgsql-docs@arkaria.postgresql.org; Thu, 14 Nov 2024 08:33:18 +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 1tBJWT-00GLW7-Hm for pgsql-docs@lists.postgresql.org; Wed, 13 Nov 2024 19:59:30 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBJWQ-001loF-6j for pgsql-docs@lists.postgresql.org; Wed, 13 Nov 2024 19:59:29 +0000 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-539e63c8678so8442999e87.0 for ; Wed, 13 Nov 2024 11:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731527966; x=1732132766; darn=lists.postgresql.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=z2MirkTl71HLwsPRzl5v5x7asUQ+L5NuqKAihC8uJSI=; b=Ix6kVcsKB7vqt54phySv49FgOZvCn8GsFa5AbT/j8RVYLzw0laaL7pSybFLIvnxI2H IKl7o2uUD9rFN8hDTCxK6MGqixOPTnkDvhVL3U6vgy6iqRY24y+szZ+2VDvRQ5Hy+9hP Ij1v4ROnSaqsr3q+h2eTjm9ONUWO3pr9KXZfraQ7/CcHR4ho7Mu3NCgc0NITcS82IPqw DT4j4g5E6J6FkY2fabrTdtT77win6sEF+FxrCuASTpHJk+dNHUslt6UT2lIDXrA9RKAl QceCqrIwtFrMCx9bw/4qRm0df0fiQI++d1keYoBkgVw52bNTo031MNjYe+RKSX41ARpX WRbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731527966; x=1732132766; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=z2MirkTl71HLwsPRzl5v5x7asUQ+L5NuqKAihC8uJSI=; b=b6TK3Yl0lF5IVCltmJZFpY+NVRsGcF/p+IJ9R1hOCGNgctu9KLSeR997OIm8DBvFVB +S0v3OlVKhcVjzq5wgiy6vbUJ1qKx3OLlDskwVf14VF2iXYu2XyABXAjiDWC4XOiDR5O IVsFjGqJh7zSRbB3BmeSEBNEPyyNu2ehqaVNnUy9ORo5PMXUcQORlw+668IJK+EEnuvH eS4Yu74oyrEUIigDoim4n72ZNDJW/WWEZab6lW361lV1pO1450oKA17EqHb79jecOc5p zGV3cKTMHo703kSxIKC4yU/r6M81fphR7OcB6BL+G+/y5kWMLOG/qy2/QVc9Q8pWTfme 2qiQ== X-Gm-Message-State: AOJu0YwWPyV2I25coKuyHNaTkICMBuFq5x0bE5HZnExQs8r08HmvJJdG 6C04NJ0kP/ZLY5KAVmImDLBiuo936T9+R37iNwEc8l4siJC80Vqt9zzWLg== X-Google-Smtp-Source: AGHT+IH8U5QsjxZCJi17Vx71pzIiyAMxFAxgDCOE5oRXJFChJcfQDlwIwAI+k5G3EFAur8RIZ3m8xg== X-Received: by 2002:a05:6512:3405:b0:53d:a1eb:a0ce with SMTP id 2adb3069b0e04-53da1eba293mr1591242e87.55.1731527965606; Wed, 13 Nov 2024 11:59:25 -0800 (PST) Received: from smtpclient.apple ([176.226.234.225]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53d826a71f0sm2338353e87.142.2024.11.13.11.59.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2024 11:59:24 -0800 (PST) From: "=?utf-8?B?ItCh0LXRgNCz0LXQuSDQnyAoU2VyZ2VpRG9zKSI=?=" X-Google-Original-From: =?utf-8?B?ItCh0LXRgNCz0LXQuSDQnyAoU2VyZ2VpRG9zKSI=?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3611F0CF-CBE5-45F4-873A-5B0D0D9216F8" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: Generated names (suffix) for constraints not described in docs Date: Thu, 14 Nov 2024 00:59:10 +0500 In-Reply-To: Cc: "pgsql-docs@lists.postgresql.org" To: "David G. Johnston" References: <712E40A2-744F-424E-AE45-95CE5BE27D82@gmail.com> X-Mailer: Apple Mail (2.3826.200.121) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_3611F0CF-CBE5-45F4-873A-5B0D0D9216F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for your reply! Perhaps it would be worthwhile to record the rules for forming the names = of indexes and constraints in the database in the documentation and in = the algorithms. In our project, we use the PostgreSQL database. And we would like to = describe the rules for naming indexes and constraints for developers so = that they are unambiguous. But the database allows you to declare = constraints without a name. And in this case, the name will be formed = according to some rules described in the algorithms in the source codes = of the database. And, it seems, this algorithm should be recorded and = described in the documentation. It would be logical if we formed the = rules for our database developers identical to the internal automatic = rules for forming names in the database, so that developers who choose = the path of automatic name formation would receive the same result as = those who set it manually in accordance with the described rules. Thank you for your time, Podrezov Sergey > 13 =D0=BD=D0=BE=D1=8F=D0=B1. 2024=E2=80=AF=D0=B3., =D0=B2 19:22, David = G. Johnston =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=BB(=D0=B0): >=20 > On Wednesday, November 13, 2024, "=D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 = =D0=9F (SergeiDos)" > wrote: >> >> = = >> >> = = >> Hello! >> In the documentation for the Constraints section = https://www.postgresql.org/docs/current/ddl-constraints.html there is a = phrase: "So, to specify a named constraint, use the key word CONSTRAINT = followed by an identifier followed by the constraint definition. (If you = can't specify a constraint name in this way, the system choose a name = for you.)" >> But nowhere in the documentation are the rules by which it generates = names on its own described. >=20 > Correct. Which means the specific name chosen is an implementation = detail that can change at any time and should not be relied upon by the = DBA. It could be a randomly generated uuid for all it matters, but we = do make some attempt to make it readable. >=20 > Since they are user-facing values I do see some benefit to defining = what is being seen, though precisely how and to what purpose I am = unsure. If you see a name it seems self-describing what it means if you = have familiarity with relational databases. Telling a user what they = will get when they execute SQL without specifying a name is not = something I would want to document. >=20 > David J. >=20 >> = >> = --Apple-Mail=_3611F0CF-CBE5-45F4-873A-5B0D0D9216F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you = for your reply!
Perhaps it would be worthwhile to record the = rules for forming the names of indexes and constraints in the database = in the documentation and in the algorithms.
In our project, we = use the PostgreSQL database. And we would like to describe the rules for = naming indexes and constraints for developers so that they are = unambiguous. But the database allows you to declare constraints without = a name. And in this case, the name will be formed according to some = rules described in the algorithms in the source codes of the database. = And, it seems, this algorithm should be recorded and described in the = documentation. It would be logical if we formed the rules for our = database developers identical to the internal automatic rules for = forming names in the database, so that developers who choose the path of = automatic name formation would receive the same result as those who set = it manually in accordance with the described rules.
Thank you = for your time,
Podrezov Sergey

13 =D0=BD=D0=BE=D1=8F=D0=B1. 2024=E2=80=AF=D0=B3., =D0=B2= 19:22, David G. Johnston <david.g.johnston@gmail.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

On Wednesday, November 13, = 2024, "=D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 =D0=9F (SergeiDos)" <podrezov.sergey@gmail.com>= ; wrote:
<= /u>
=
<= /u>
=
=
=
Hello!
In the = documentation for the Constraints section https://www.postgresql.org/docs/current/ddl-constra= ints.html there is a phrase: "So, to specify a named = constraint, use the key word CONSTRAINT followed by an identifier = followed by the constraint definition. (If you can't specify a = constraint name in this way, the system choose a name for = you.)"
But nowhere in the documentation are the rules by which = it generates names on its own = described.

Correct.  Which means the specific name chosen = is an implementation detail that can change at any time and should not = be relied upon by the DBA.  It could be a randomly generated uuid = for all it matters, but we do make some attempt to make it = readable.

Since they are user-facing values I = do see some benefit to defining what is being seen, though precisely how = and to what purpose I am unsure.  If you see a name it seems = self-describing what it means if you have familiarity with relational = databases.  Telling a user what they will get when they execute SQL = without specifying a name is not something I would want to = document.

David = J.


= --Apple-Mail=_3611F0CF-CBE5-45F4-873A-5B0D0D9216F8--