Re: bogus error message for ALTER TABLE ALTER CONSTRAINT
От | Amul Sul |
---|---|
Тема | Re: bogus error message for ALTER TABLE ALTER CONSTRAINT |
Дата | |
Msg-id | CAAJ_b97hd-jMTS7AjgU6TDBCzDx_KyuKxG+K-DtYmOieg+giyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bogus error message for ALTER TABLE ALTER CONSTRAINT (Álvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: bogus error message for ALTER TABLE ALTER CONSTRAINT
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: