PostgreSQL中为约束命名的写法是否存在实际优势？

我本身具备SQL基础，创建表时习惯直接在字段后附加NOT NULL、PRIMARY KEY约束，写法如下：

CREATE TABLE Customer 
(
    CustNo VARCHAR(8) NOT NULL PRIMARY KEY, 
    CustName VARCHAR(30) NOT NULL, 
    Address VARCHAR(50) NOT NULL, 
    Internal CHAR(1) NOT NULL, 
    Contact VARCHAR(35) NOT NULL, 
    Phone VARCHAR(11) NOT NULL, 
    City VARCHAR(30) NOT NULL,
    State VARCHAR(2) NOT NULL, 
    Zip VARCHAR(10) NOT NULL
);

但最近学习的教程中，PostgreSQL示例采用了为每个NOT NULL约束单独命名，并将PRIMARY KEY约束单独定义的写法（Oracle和MySQL示例未采用此方式），写法如下：

CREATE TABLE Customer 
(
    CustNo VARCHAR(8) CONSTRAINT CustNoNotNull NOT NULL, 
    CustName VARCHAR(30) CONSTRAINT CustNameNotNull NOT NULL, 
    Address VARCHAR(50) CONSTRAINT AddressNotNull NOT NULL, 
    Internal CHAR(1) CONSTRAINT InternalNotNull NOT NULL, 
    Contact VARCHAR(35) CONSTRAINT ContractNotNull NOT NULL, 
    Phone VARCHAR(11) CONSTRAINT CPhoneNotNull NOT NULL, 
    City VARCHAR(30) CONSTRAINT CityNotNull NOT NULL,
    State VARCHAR(2) CONSTRAINT StateNotNull NOT NULL, 
    Zip VARCHAR(10) CONSTRAINT zipNotNull NOT NULL, 

    CONSTRAINT PK_CUSTOMER PRIMARY KEY (CustNo) 
);

这种写法确实存在不少实际优势：

• 报错定位更高效：当约束校验失败时，数据库会返回对应的约束名称。自定义的约束名（比如CustNoNotNull）比数据库自动生成的默认名称（如PostgreSQL自动生成的customer_custno_notnull）更直观，能一眼锁定是哪个字段的非空约束出了问题，减少排查时间。
• 约束操作更便捷：后续如果需要修改或删除某个约束，显式命名的约束可以直接通过名称执行操作，比如ALTER TABLE Customer DROP CONSTRAINT CustNameNotNull;。要是用隐式命名的约束，你得先查询数据库生成的默认名称，多了额外步骤，效率更低。
• 代码可读性与团队协作更友好：显式命名让表结构的约束定义更清晰，团队成员能快速理解每个约束的作用。尤其是表结构复杂、约束较多时，统一的命名规范（比如PK_表名、字段名NotNull）能让代码风格保持一致，降低维护成本。
• 跨库迁移适配性更强：虽然不同数据库对约束命名的处理有差异，但显式命名的方式在多数主流数据库中都支持。当需要迁移数据库时，显式命名的约束能避免因自动生成的约束名不一致导致的适配问题，让迁移过程更顺畅。

内容的提问来源于stack exchange，提问作者user19695340