Received: from golem.jpl.nasa.gov (root@hectic-1.jpl.nasa.gov [128.149.68.203]) by hub.org (8.8.8/8.7.5) with ESMTP id NAA13344 for ; Thu, 10 Sep 1998 13:10:55 -0400 (EDT) Received: from alumni.caltech.edu (localhost [127.0.0.1]) by golem.jpl.nasa.gov (8.8.5/8.8.5) with ESMTP id RAA24717; Thu, 10 Sep 1998 17:06:49 GMT Sender: tgl@mythos.jpl.nasa.gov Message-ID: <35F80729.48E37A17@alumni.caltech.edu> Date: Thu, 10 Sep 1998 17:06:49 +0000 From: "Thomas G. Lockhart" Organization: Caltech/JPL X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.30 i686) MIME-Version: 1.0 To: Bruce Momjian CC: hackers@postgreSQL.org Subject: Re: [HACKERS] open 6.4 items References: <199809101425.KAA00887@candle.pha.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > allow multiple generic operators in expressions without the use of > parentheses I could just let this one go until it dies a quiet death, but... To parse "multiple generic operators", per the example select oid @ oid @ oid from table; one would have to change the associativity of many operators from non-associative (the correct assumption) to left- or right associative (the wrong thing to do). If we are going to allow operator extensibility we cannot make assumptions about the precedence order of operators, and should require parentheses to break the ambiguity. Unless someone has a good proposal on how to change the standard rules of arithmetic, or on how to change the parser to allow operator-dependent precedence in an extensible way, then we shouldn't bother tracking this as a problem statement imho. - Tom