X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id EC3D752932
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Mon, 15 Aug 2005 23:02:46 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 05107-07
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Tue, 16 Aug 2005 02:02:45 +0000 (GMT)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by svr1.postgresql.org (Postfix) with ESMTP id 0D4005292D
	for <pgsql-sql@postgresql.org>; Mon, 15 Aug 2005 23:02:44 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j7G22e84020490;
	Mon, 15 Aug 2005 22:02:40 -0400 (EDT)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Dario Bahena Tapia <dario.mx@gmail.com>, pgsql-sql@postgresql.org
Subject: Re: Parentheses in FROM clause and evaluation order. 
In-reply-to: <20050815183859.U67925@megazone.bigpanda.com> 
References: <200508110042.j7B0g1TZ015835@panselmo.fciencias.unam.mx>
	<20050815065906.K33261@megazone.bigpanda.com>
	<3d104d6f05081509345067d83b@mail.gmail.com>
	<20050815183859.U67925@megazone.bigpanda.com>
Comments: In-reply-to Stephan Szabo <sszabo@megazone.bigpanda.com>
	message dated "Mon, 15 Aug 2005 18:48:28 -0700"
Date: Mon, 15 Aug 2005 22:02:40 -0400
Message-ID: <20489.1124157760@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006]
X-Spam-Level: 
X-Archive-Number: 200508/110
X-Sequence-Number: 22338

Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> On Mon, 15 Aug 2005, Dario Bahena Tapia wrote:
>> The final result seems to be the same, I just was curious about the
>> standard behavior. Does the SQl says something about this execution
>> order?

> I believe SQL defines the order to pay attention to parens, so A join (B
> join C) style clauses result in a "table" being derived from B join C and
> another from A joined with that table.

SQL only constrains the results, though.  It does not forbid the
implementation from doing the work in whatever way seems best to it,
so long as the results are the same (and "same" does not consider
row ordering).

For example, SQL92 3.3.4.4 says

         A conforming implementation is not required to perform the exact
         sequence of actions defined in the General Rules, but shall achieve
         the same effect on SQL-data and schemas as that sequence.


			regards, tom lane