| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: ERROR: no NOT NULL constraint found to drop |
| Date: | 2023-04-12 00:31:51 |
| Message-ID: | ZDX79xxrpmbDo5vx@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Apr 10, 2023 at 09:46:59AM -0400, Tom Lane wrote:
> It's still good to know about it for next time. The issue I guess is
> that LIKE with no options propagates column attnotnull bits, but not
> constraints, so we now have an inconsistency: t2.c has attnotnull set
> but there is nothing in pg_constraint to justify it. It seems to me
> we're going to have to think about what we want to happen in this
> case. In a green field we'd probably not propagate NOT NULL unless
> told to copy constraints ... but is it okay to break functional
> compatibility with the old behavior?
I am not sure about that, TBH, though I would tend to not break
compatibility just for the sake of breaking it. Anyway, shouldn't we
have a test that does a DROP NOT NULL after a LIKE copies it? At
least, we'll be able to track that.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2023-04-12 09:05:55 | Re: BUG #17862: Overall query cost ignores window function |
| Previous Message | PG Bug reporting form | 2023-04-12 00:23:52 | BUG #17891: MAIF - Strange behavior on Grants with Groups |