Bruno Wolff III (b...@wolff.to)

On Wed, Sep 05, 2007 at 10:37:18 +1000,
  Andrew Maclean <andrew.amaclean@gmail.com> wrote:
> In Table 9.4 of the documentation atan2 is described as follows:
>   atan2(*x*, *y*) inverse tangent of *x*/*y*
>
> I am sure it should read as:
>   atan2(*y*, x) inverse tangent of y/x

Aren't those two statements sayiong the same thing?
You've just switched the names 'x' and 'y' and not changed their relationships.

>
>
> You can easily test this:
> If y = 2, x = 1, then degrees(atan(y/x)) =63.4 but if we proceed according
> to the documentation; degrees(atan2(x,y))=degrees(atan2(1,2))=25.6 which is
> not the same as degrees(atan(y/x)).

In this example you switched things around part way thorugh. atan2(1,2)
is the atan of (1/2), not atan(2/1) as used at the beginning of the example.

On Sat, Jun 30, 2007 at 09:29:23 +0200,
  Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hello,
>
> I have not Oracle, so I cannot test it, but PostgreSQL implementation
> respect Oracle:
>
> http://archives.postgresql.org/pgsql-patches/2005-06/msg00431.php

Maybe that reference was for an earlier version of Oracle and the definition
changed at some point? I only have access to version 9 and greatest and
lest are strict there.

On Sat, Jun 30, 2007 at 00:15:42 -0400,
  Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Andrej Ricnik-Bay" <andrej.groups@gmail.com> writes:
> > On 6/30/07, Bruno Wolff III <bruno@wolff.to> wrote:
> >> I was recently doing some stuff with greatest() on oracle (9.2.0.8.0) and
> >> noticed that it returned null if ANY of the arguments were null. Out of
> >> curiosity I checked postgres' definition of that function and found that it
> >> returns null only if ALL of the arguments are null.
>
> > W/o knowing the SQL standard (just from what I'd perceive
> > as sensible) I'd say Oracle is broken. :}
>
> Hmm ... I fear Oracle's behavior is more correct, because if any
> argument is null (ie, unknown), then who can say what the greatest or
> least value is? It's unknown (ie, null). But I suspect our behavior
> is more useful.  Comments?

In my case I would have prefered Postgres' behavior. I wanted to take
the max of values coming from two columns by taking the greatest of
two subselects. I ended up rewriting the query to take the max of a union.
The annoying thing was I didn't have a good way to use coalesce as I wanted
to get a null if both subselects were empty. Also what value should I have
used in a coalesce to guaranty still getting the maximum? I think having
it work like aggregates and ignoring null values is more convenient.
However if the feature was added for oracle compatibility then not working
the same is an issue.

I was just hoping that perhaps the fact that the semantics are different
between oracle and postgres would get noted somewhere so people porting
would have a better chance to become aware of the issue.

The following is just FYI.
I was recently doing some stuff with greatest() on oracle (9.2.0.8.0) and
noticed that it returned null if ANY of the arguments were null. Out of
curiosity I checked postgres' definition of that function and found that it
returns null only if ALL of the arguments are null.

On Fri, May 25, 2007 at 18:45:15 -0700,
  Craig James <craig_james@emolecules.com> wrote:
> We're thinking of building some new servers. We bought some a while back
> that have ECC (error correcting) RAM, which is absurdly expensive compared
> to the same amount of non-ECC RAM. Does anyone have any real-life data
> about the error rate of non-ECC RAM, and whether it matters or not? In my
> long career, I've never once had a computer that corrupted memory, or at
> least I never knew if it did. ECC sound like a good idea, but is it
> solving a non-problem?

In the past when I purchased ECC ram it wasn't that much more expensive
than nonECC ram.

Wikipedia suggests a rule of thumb of one error per month per gigabyte,
though suggests error rates vary widely. They reference a paper that should
provide you with more background.