On Tue, Oct 3, 2023 at 10:05 AM David G. Johnston <david.g.johns...@gmail.com> wrote: >> The real-world use case, at least for me, is when using an ORM. For large >> object-graphs ORMs have a tendency to INSERT first with NULLs then UPDATE >> the “NOT NULLs” later. >> >> “Rewrite the ORM” is not an option for most of us… > > Between this and Vik comment it sounds like we should probably require a > patch in this area to solve both the not null and check constraint deferral > omissions then, not just one of them (alternatively, let’s solve the not null > one first).
I have a couple of problems with this comment: 1. I don't know which of Vik's comments you're talking about here, but it seems to me that Vik is generally in favor of this feature, so I'm a bit surprised to hear that one of his comments led you to think that it should be burdened with additional requirements. 2. I don't think it's a good idea for the same patch to try to solve two problems unless they are so closely related that solving one without solving the other is not sensible. It is a good policy for the community to accept incremental progress provided it doesn't break things along the way. Smaller patches are way easier to get committed, and then we get some of the feature sooner instead of all of it some more distant point in the future or never. Furthemore, forcing additional requirements onto patch submitters as a condition of patch acceptance is extremely demoralizing to submitters, and we should not do it without an excellent reason. Mind you, I'm not against this patch handling both CHECK and NOT NULL constraints if that's the most sensible way forward, especially in view of Álvaro's recent work in that area. But it sort of sounds like you're just trying to sink the patch despite it being a feature that is both in the SQL standard and has real use cases which have been mentioned on the thread, and I don't really like that. In the interest of full disclosure, I do work at the same company as Dilip and Himanshu, so I might be biased. But I feel like I would be in favor of this feature no matter who proposed it, as long as it was well-implemented. It's always struck me as odd that we allow deferring some types of constraints but not others, and I don't understand why we'd want to block closing that gap unless there is some concrete downside to so doing. -- Robert Haas EDB: http://www.enterprisedb.com
