Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: "John B. Scalia" <jscalia@cityblueprinting.com>
Subject: Re: Bug in psql - Postgresql 7.3.1?
Date: Fri, 3 Oct 2003 13:16:10 -0700
User-Agent: KMail/1.4.3
References: <004401c389e9$ac7acc60$2501a8c0@John>
In-Reply-To: <004401c389e9$ac7acc60$2501a8c0@John>
Cc: pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200310031315.52146.josh@agliodbs.com>

John,

> Yeah, I figured out my SQL was bad and had switched to the comma
> separated version, instead. In my mind, the first form should have
> caused an error. I've attached a cut-and-pasted session from psql where
> I used this syntax on a test table. While edited for brevity and to
> obscure passwords, this is how the output appeared.

Here's your problem:

accounting=3D# update all_user set usr_current =3D True AND usr_location =
=3D 1002;
UPDATE 3

PostgreSQL interpreted the expression "True AND usr_location =3D 1002" as a=
=20
single, unitary, boolean expression.   AND is the boolean AND operator.=20=
=20
Since none of the users on your list had "usr_location =3D 1002", you got:

user_current =3D (True AND (usr_location =3D 1002))
user_current =3D (True AND False)
user_current =3D False

Since all 3 rows already had false, they did not appear to get updated, but=
 in=20
fact they were.

Time to look up your order of operations!

--=20
-Josh Berkus
 Aglio Database Solutions
 San Francisco