On Mon, Jun 5, 2017 at 5:59 PM, Ken Tanzer <ken.tan...@gmail.com> wrote:
> I can't really make this an FK. I can (and probably will) put this into a >>> trigger. Although it seems like an extra layer of wrapping just to call a >>> function. I'm curious if there's any conceptual reason why constraints >>> couldn't (as an option) be restored after all the data is loaded, and >>> whether there would be any negative consequences of that? I could see if >>> your data still didn't pass the CHECKs, it's already loaded. But the >>> constraint could then be marked not valid? >>> >> >> Not sure why just know that if I stay within the guidelines it works, if >> I do not its does not work:) >> >> > That's fair enough, leaving aside the curiosity part. Usually though the > things you can't do just aren't allowed. It's easier to overlook something > that you shouldn't (but can) do! > > I find in life most things that are prohibited are actually doable - you're just punished if you get caught doing them. In all seriousness though I agree it would be nice if that's how this worked; but decades of historical precedent makes actual preventive enforcement difficult if not impossible. Since "test your backups" covers this potential problem, and so many possible others, any non-trivial effort to solve the actual problem is hard to justify spending time on. I do get the "make \d show relevant information" argument and that is one that seems easier to solve, since adding explicit dependencies during trigger creation would be a purely new feature. David J.
