DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=Bjcz0etoqYbWKECsSEp0iOqdYU8nIpjbASQXiIVPLdQCP+WeCYStI3BVOHe1jPYIAC0GGMKk1JIiHkaw8MiLE9hOW6foGLN/ykMCc9QKZhlmQQbBm3/RHJK7Rx2kgGdA0yUZ0QJ5pgUCqF7BHOdd/mWF7XrVfuPav5O5+tXFIDk=
Message-ID: <a2de01dd0601020528j39555990i@mail.gmail.com>
Date: Mon, 2 Jan 2006 13:28:30 +0000
From: Peter Childs <peterachilds@gmail.com>
To: pgsql-sql@postgresql.org
Subject: delete from a using b in postgres 8.1.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_7700_20586447.1136208510573"

------=_Part_7700_20586447.1136208510573
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

a command such as

delete from a using b where a.one=3Db.one and b.two=3D'foo';

works fine in 8.1 but fails totally in 8.0 however

delete from a where a.one=3Db.one and b.two=3D'foo';

works fine in 8.0 and bellow but fails in 8.1 unless you have the
add_missing_from option set to true in 8.1
Even then it produces a nasty warning.

This can break tones of clients admittedly the work around is quick but not
particularly neat. What do the other sql database do and is this just
another inconstancy in SQL?

I realise this was done to fix a bug but its a nasty sitting there that man=
y
client developers are going to miss it before it goes back to the end user.
I also don't think  this has been made particularly clear in changes.

Peter Childs

------=_Part_7700_20586447.1136208510573
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

a command such as<br>
<br>
delete from a using b where a.one=3Db.one and b.two=3D'foo';<br>
<br>
works fine in 8.1 but fails totally in 8.0 however<br>
<br>
delete from a where a.one=3Db.one and b.two=3D'foo';<br>
<br>
works fine in 8.0 and bellow but fails in 8.1 unless you have the add_missi=
ng_from option set to true in 8.1 <br>
Even then it produces a nasty warning.<br>
<br>
This can break tones of clients admittedly the work around is quick but
not particularly neat. What do the other sql database do and is this
just another inconstancy in SQL?<br>
<br>
I realise this was done to fix a bug but its a nasty sitting there that
many client developers are going to miss it before it goes back to the
end user. I also don't think&nbsp; this has been made particularly
clear in changes.<br>
<br>
Peter Childs<br>

------=_Part_7700_20586447.1136208510573--