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 нояб. 2024 г., в 19:22, David G. Johnston <david.g.johns...@gmail.com> > написал(а): > > On Wednesday, November 13, 2024, "Сергей П (SergeiDos)" > <podrezov.ser...@gmail.com <mailto:podrezov.ser...@gmail.com>> wrote: >> <https://translate.google.com/about/?hl=ru> >> <https://policies.google.com/?hl=ru> >> <https://support.google.com/translate/?hl=ru> >> <https://www.google.com/about?hl=ru> >> <https://translate.google.com/about/?hl=ru> >> <https://policies.google.com/?hl=ru> >> <https://support.google.com/translate/?hl=ru> >> <https://www.google.com/about?hl=ru> >> 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. > > 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. > >> <https://translate.google.com/history> <https://translate.google.com/saved> >> <https://translate.google.com/history> <https://translate.google.com/saved>
