X-Original-To: pgsql-sql@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id E470B47592C for ; Thu, 10 Apr 2003 12:10:25 -0400 (EDT) Received: from europa.janwieck.net (h00045a2e4e7c.ne.client2.attbi.com [24.131.181.55]) by postgresql.org (Postfix) with ESMTP id 02F54474E42 for ; Thu, 10 Apr 2003 12:10:21 -0400 (EDT) Received: from Yahoo.com (linksys.janwieck.net [192.168.192.1]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id h3AGAOa06713; Thu, 10 Apr 2003 12:10:24 -0400 Message-ID: <3E959742.E35C53BB@Yahoo.com> Date: Thu, 10 Apr 2003 12:09:38 -0400 From: Jan Wieck Organization: Home X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Ian Barwick Cc: pgsql-sql@postgresql.org Subject: Re: INSERT INTO ... SELECT (PostgreSQL vs. MySQL) References: <200304101627.43804.barwick@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/167 X-Sequence-Number: 12868 Ian Barwick wrote: > > I'm currently "porting" a smallish application from Postgres > to MySQL [*]. I see that with MySQL it is not possible to perform > > INSERT INTO ... SELECT > > when the target table is the same as the source table, e.g. > > INSERT INTO foo (abc, xyz) > SELECT abc, xyz FROM foo WHERE id = 1 > > MySQL says: ERROR 1066: Not unique table/alias: 'foo' > > This statement works as expected in both PostgreSQL (at least 7.3.x) > and also in Oracle 8i. Microsoft SQL-Server 2000 has no problem with it either. > > The MySQL manual says: > > "The target table of the INSERT statement cannot appear in the > FROM clause of the SELECT part of the query because it's forbidden > in standard SQL to SELECT from the same table into which you are > inserting. (The problem is that the SELECT possibly would find > records that were inserted earlier during the same run. > When using subquery clauses, the situation could easily be very > confusing!)" I didn't find anything like that in 15.8 of the SQL3 draft. Must be in small print on the backside of the PostScript file I have. Sure, the spec can be a bit confusing if one looks at it for the first time. I didn't know that it confused the MySQL developer(s) that much. For sure is it another perfect example why one has to be very carefull when reading the MySQL documentation. Half of the reasons for why MySQL differs from the standard or does not support basic standard functionality are simply made up. The manual is full of lame excuses for missing features and full of wrong or even dangerous advices or workarounds every database professional can only shake his head over. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #