Обсуждение: RE: [INTERFACES] JDBC next() method

On Saturday, 24 April 1999 6:45, herouth maoz [SMTP:herouth@oumail.openu.ac.il] 
wrote:
> No, the question is whether Postgres's behaviour - of returning a row with
> a null field in case no rows fell into the WHERE category - is compatible
> with other databases, or indeed with the SQL standard. I don't have the
> standard in front of me at this moment. But you must understand that this
> is how PostgreSQL behaves, no matter whether your frontend is in Java,
> python, perl or C. It's not a question of JDBC.

I concede your point on that.  I'm just obsessing over the ultimate result of 
this quirk(?) - independence of the application.

>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 - I guess costs and complexity of the fix will 
determine that (although it is always better to fix it at the source).  Of 
course, hiding it in the abstraction layer means you need to do the same for 
every interface (which is a headache for maintainers).

This is just speculation and musing, in any case, as I am not sure what the SQL 
standard says with respect to this limit case (where a table is empty).  More 
research needed I suppose. :)

JonB.

Jon Barnett <jbarnett@pobox.com> 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