Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add pg_constraint rows for not-null constraints

  1. Postgres 17 domains with NOT NULL and pg_get_constraintdef()

    shammat@gmx.net — 2025-01-08T11:15:19Z

    Hello,
    
    I am not sure if this is intended behavior or an oversight/bug.
    
    Assume the following domain definition:
    
        CREATE DOMAIN sample_domain AS numeric(12,2) NOT NULL constraint positive_value CHECK (value > 0);
    
    Up until Postgres 16 it was possible to retrieve the domain constraints using:
    
        select t.typname,
               pg_catalog.pg_get_constraintdef(ci.oid, true)
        from pg_catalog.pg_type t
          join pg_catalog.pg_constraint ci on ci.contypid = t.oid
        where t.typtype = 'd'
          and t.typname = 'sample_domain'
    
    However, because the domain is defined with NOT NULL, this fails with
    
    > ERROR: invalid constraint type "n"
    
    with 17.2 on Windows and Linux.
    
    This is a result of storing the NOT NULL constraint in pg_constraint
    and can easily be avoided by either using contype <> 'n' or by not calling
    pg_get_constraintdef if contype = 'n'
    
    Is this a bug/oversight in pg_get_constraintdef() or does it just not support NOT NULL
    constraints? The manual does not show any restriction on the usage.
    
    
    
    
    
    
    
  2. Re: Postgres 17 domains with NOT NULL and pg_get_constraintdef()

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-01-08T13:10:45Z

    On 2025-Jan-08, shammat@gmx.net wrote:
    
    Hello,
    
    > However, because the domain is defined with NOT NULL, this fails with
    > 
    > > ERROR: invalid constraint type "n"
    > 
    > with 17.2 on Windows and Linux.
    > 
    > This is a result of storing the NOT NULL constraint in pg_constraint
    > and can easily be avoided by either using contype <> 'n' or by not calling
    > pg_get_constraintdef if contype = 'n'
    
    Yeah, thanks for the report -- this is clearly a bug and it was fixed
    already in the 17 branch, but it's not been released yet.  It'll be in
    the February release.
    
    Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
    Branch: master [09d09d429] 2024-11-27 13:50:27 +0100
    Branch: REL_17_STABLE [6e793582b] 2024-11-27 13:50:27 +0100
    
        Fix pg_get_constraintdef for NOT NULL constraints on domains
        
        We added pg_constraint rows for all not-null constraints, first for
        tables and later for domains; but while the ones for tables were
        reverted, the ones for domains were not.  However, we did accidentally
        revert ruleutils.c support for the ones on domains in 6f8bb7c1e961,
        which breaks running pg_get_constraintdef() on them.  Put that back.
        
        This is only needed in branch 17, because we've reinstated this code in
        branch master with commit 14e87ffa5c54.  Add some new tests in both
        branches.
        
        I couldn't find anything else that needs de-reverting.
        
        Reported-by: Erki Eessaar <erki.eessaar@taltech.ee>
        Reviewed-by: Magnus Hagander <magnus@hagander.net>
        Discussion: https://postgr.es/m/AS8PR01MB75110350415AAB8BBABBA1ECFE222@AS8PR01MB7511.eurprd01.prod.exchangelabs.com
    
    -- 
    Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
    "Right now the sectors on the hard disk run clockwise, but I heard a rumor that
    you can squeeze 0.2% more throughput by running them counterclockwise.
    It's worth the effort. Recommended."  (Gerry Pourwelle)
    
    
    
    
  3. Re: Postgres 17 domains with NOT NULL and pg_get_constraintdef()

    shammat@gmx.net — 2025-01-08T18:39:25Z

    Am 08.01.25 um 14:10 schrieb Alvaro Herrera:
    >> However, because the domain is defined with NOT NULL, this fails with
    >>
    >>> ERROR: invalid constraint type "n"
    >>
    >> with 17.2 on Windows and Linux.
    >>
    >> This is a result of storing the NOT NULL constraint in pg_constraint
    >> and can easily be avoided by either using contype <> 'n' or by not calling
    >> pg_get_constraintdef if contype = 'n'
    >
    > Yeah, thanks for the report -- this is clearly a bug and it was fixed
    > already in the 17 branch, but it's not been released yet.  It'll be in
    > the February release.
    
    Thanks for the confirmation.