Re: bogus error message for ALTER TABLE ALTER CONSTRAINT - Mailing list pgsql-hackers

From Amul Sul
Subject Re: bogus error message for ALTER TABLE ALTER CONSTRAINT
Date
Msg-id CAAJ_b97hd-jMTS7AjgU6TDBCzDx_KyuKxG+K-DtYmOieg+giyQ@mail.gmail.com
Whole thread Raw
In response to Re: bogus error message for ALTER TABLE ALTER CONSTRAINT  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: bogus error message for ALTER TABLE ALTER CONSTRAINT
List pgsql-hackers
On Tue, Mar 11, 2025 at 1:56 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2025-Mar-11, Amul Sul wrote:
>
> > On Mon, Mar 10, 2025 at 11:29 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >
> > > I fleshed this out more fully and I think 0001 is good enough to commit.
> >
> > The approach looks good to me, but instead of adding a CAS_flags struct, could
> > we use macros like SEEN_DEFERRABILITY(bits), SEEN_ENFORCEABILITY(bits),
> > etc.? We can simply pass cas_bits to these macros, and to avoid the error
> > from processCASbits(), we can pass NULL for constrType.
>
> Ah yeah, I thought of this too at first, but didn't actually code it
> because I thought it'd be messier.  Trying to do it naively doesn't
> work, because it's not enough to test whether each bit is true or false
> -- what you need to know is whether an option was specified for each
> bit, in either direction.  So we'd need a separate bitmask, we can't
> pass the existing 'bits' mask.  And at that point, it's not any better
> to have a bitmask, and a stack-allocated struct of booleans is just
> easier to write.
>

I was thinking of something like the attached, which includes your
test cases from 0001. Perhaps the macro name could be improved.

Regards,
Amul

Attachment

pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Selectively invalidate caches in pgoutput module
Next
From: John Naylor
Date:
Subject: Re: Improve CRC32C performance on SSE4.2