| From: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Amul Sul <sulamul(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: bogus error message for ALTER TABLE ALTER CONSTRAINT |
| Date: | 2025-03-11 08:26:43 |
| Message-ID: | 202503110826.ttskpa5mokuu@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2025-Mar-11, Amul Sul wrote:
> On Mon, Mar 10, 2025 at 11:29 PM Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos. Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2025-03-11 08:29:15 | Re: [PATCH] Add reverse(bytea) |
| Previous Message | jian he | 2025-03-11 08:23:42 | Re: Emitting JSON to file using COPY TO |