Hi, I've been having a look around to see what would it take to implement the syntax in the subject, completing a patch posted by Sussane Ebrecht two years ago.
As far as I can tell, the first problem is in the grammar. The SQL spec mandates <multiple value expression> as a production for the expression at the right of the equal sign. This enters a *large* chain of productions that can end up in a lot of things, and for which I don't think we have a production in our grammar. In fact I think we have special cases for many of the things that can be derived from here, so maybe some things will have to be reworked in order to support all the stuff that the standard mandates. I'll refrain from doing this initially, and will focus on getting the simpler cases working. But then there's the matter of how to represent it from the grammar inwards. At first I thought of creating a new parse node type, say MultiResTarget that would replace ResTarget in UpdateStmt, and get it from there into the optimizer and executor. However, this seems to require creating a new node for TargetEntry too, and duplicate logic for all of that. As far as transformTargetList is concerned this wouldn't be much of a problem, but from there onwards it's pretty complex -- it requires a lot of duplicate logic. In fact I think it would cause the current code which is common for UPDATE/INSERT/SELECT/DELETE to split in two, one for UPDATE and one for the rest, which looks ungood. So is this the right way to approach the problem, or am I missing some simpler way? Perhaps, for example, I should be treating normal updates as currently, and add a new member to UpdateStmt that would hold multi-column expressions. But I'm not sure if that would work at all. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
