On Thu, Jul 12, 2018 at 05:12:21PM +0300, Heikki Linnakangas wrote: > Doesn't have to be a trigger, could be a CHECK constraint, datatype input > function, etc. Admittedly, having a datatype input function that inserts to > the table is worth a "huh?", but I'm feeling very confident that we can > catch all such cases, and some of them might even be sensible.
Sure, but do we want to be that invasive? Triggers are easy enough to block because those are available directly within cstate so you would know if those are triggered. CHECK constraint can be also easily looked after by looking at the Relation information, and actually as DEFAULT values could have an expression we'd want to block them, no? The input datatype is well, more tricky to deal with as there is no actual way to know if the INSERT is happening within the context of a COPY and this could be just C code. One way to tackle that would be to enforce the optimization to not be used if a non-system data type is used when doing COPY... Disabling entirely the optimization for any relation which has a CHECK constraint or DEFAULT expression basically applies to a hell lot of them, which makes the optimization, at least it seems to me, useless because it is never going to apply to most real-world cases. -- Michael
signature.asc
Description: PGP signature