On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund <and...@2ndquadrant.com> wrote: > Meh. A understandable syntax wouldn't require the pullups with a special > scan node and such.
Well, in general ExecModifyTable()/ExecUpdate() trusts the tid passed to match the qual in the query. Unless you're willing to give up on the idea of having a qual on the update (other than something like an ON CONFLICTS qual, obviously) I think you'll probably end up with some kind of pseudo-scan node anyway, if only for consistency with how things already work, to give you somewhere to show the Filter in explain output and so on. ExecScan() probably needs to ExecQual(). Inserts don't have scan nodes, but updates do, and so it seems pretty odd to make the "Insert" node (a ModifyTable node) pullup from a result node (as always), and the "Update" node (also a ModifyTable node) treat the first ModifyTable node as its own pseudo-scan node, when in fact we are scanning the heap in a manner not unlike a conventional update. Or do you envision a second result node where an update qual might be evaluated? I am not enthused about either possibility. The idea of not having the ability to put a predicate on the update at all, much like the MySQL thing isn't completely outrageous, but it certainly isn't going to go down well those that have already expressed concerns about how much of a foot gun this could be. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers