Received: from trends.net (root@clio.trends.ca [209.47.148.2]) by hub.org (8.9.3/8.9.1) with ESMTP id MAA00862 for ; Sat, 24 Apr 1999 12:18:24 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by trends.net (8.8.8/8.8.8) with ESMTP id MAA20970 for ; Sat, 24 Apr 1999 12:02:44 -0400 (EDT) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA23826; Sat, 24 Apr 1999 12:00:46 -0400 (EDT) To: "jbarnett@pobox.com" cc: "'herouth maoz'" , "'pgsql-interfaces@hub.org'" Subject: Re: [INTERFACES] JDBC next() method In-reply-to: Your message of Sat, 24 Apr 1999 10:45:34 +1000 <01BE8E3F.959B0140.jbarnett@pobox.com> Date: Sat, 24 Apr 1999 12:00:46 -0400 Message-ID: <23824.924969646@sss.pgh.pa.us> From: Tom Lane Jon Barnett writes: > From a practicalities point of view, if the result is not compliant > with the SQL standard, the question is whether to hide it in the > abstraction layer (JDBC driver) or fix it at the source If you can demonstrate that this behavior [NULL result from aggregate functions] is not compliant with the SQL92 standard, then the Postgres backend will get fixed. There's been discussion of this point before on the hackers list, with some people feeling that the current behavior is OK and others not happy with it, but so far no one has made a convincing case about what the standard expects. regards, tom lane