Обсуждение: INSERT .. SET syntax
Hi, Here's a patch for $SUBJECT. I'll probably work on the docs a bit more before the next CF, but I thought I'd post it anyway. .m
Вложения
On Mon, Jul 4, 2016 at 1:06 AM, Marko Tiikkaja <marko@joh.to> wrote: > Hi, > > Here's a patch for $SUBJECT. I'll probably work on the docs a bit more > before the next CF, but I thought I'd post it anyway. > I could see that it can be useful in certain cases as described in the documentation part of the patch. I noticed that you have used transformUpdateTargetList() to generate expression list for this case, but that function raises some internal errors which indicates that error is from Update. I think that might be misleading to users, if they ever got raised. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Hello hello, Here's a rebased and updated patch for $SUBJECT for the September commit fest. .m
Вложения
On 08/31/2016 04:12 PM, Marko Tiikkaja wrote: > Hello hello, > > Here's a rebased and updated patch for $SUBJECT for the September commit > fest. Review: This patch is pretty straightforward, using mostly already existing infrastructure. I tried to break it in various ways and could not. I do have a few comments, though. In insert.sgml, some things are <replaceable class="parameter"> and some are <replaceable class="PARAMETER">. I don't expect this patch to fix those inconsistencies, but it should certainly not perpetuate them. This code comment in gram.y took me a while to figure out: +/* + * This is different from set_clause_list used in UPDATE because the SelectStmt + * syntax already does everything you might want to do in an in INSERT. + */ If the SelectStmt is all we need, why is this patch here? I would prefer wording such as "This is different from set_clause_list used in UPDATE because we don't want multiple_set_clause. The INSERT INTO ... SELECT variant may be more appropriate in such cases." Or something. Aside from those trivialities, the main question about this patch is if we actually want it. It is not standard SQL syntax, and the only other product I've located that uses it (or anything like it) is MySQL. However, I can see how it would be a huge win for very wide tables and so my personal opinion is to accept this syntax as a PostgreSQL extension to the standard. Marking ready for committer, the minor gripes above notwithstanding. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 3 July 2016 at 20:36, Marko Tiikkaja <marko@joh.to> wrote: > Here's a patch for $SUBJECT. I'll probably work on the docs a bit more > before the next CF, but I thought I'd post it anyway. I think this should be Returned With Feedback. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 09/05/2016 03:58 PM, Simon Riggs wrote: > On 3 July 2016 at 20:36, Marko Tiikkaja <marko@joh.to> wrote: > >> Here's a patch for $SUBJECT. I'll probably work on the docs a bit more >> before the next CF, but I thought I'd post it anyway. > > I think this should be Returned With Feedback. You're probably right (even though you're quoting the wrong message), so I've changed it to that. Marko, please resubmit an updated patch. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support