fail to provide the function itself.  Not sure how we escaped testing anything
later than 7.3 on such cases, but they still exist, as per André Volpato's
report about AIX 5.3.

unary minus operators.  We weren't attempting to prevent minus zero anywhere
else; in view of our gradual trend to make the float datatypes more IEEE
standard compliant, we should allow minus zero here rather than disallow it
elsewhere.

We don't, however, expect that all platforms will produce minus zero, so
we need to adjust the one affected regression test to allow both results.

Per discussion of bug #4660.

(In passing, clean up a couple other minor infelicities in float.c.)

Hitoshi Harada, with some kibitzing from Heikki and Tom.

where Datum is 8 bytes wide.  Since this will break old-style C functions
(those still using version 0 calling convention) that have arguments or
results of these types, provide a configure option to disable it and retain
the old pass-by-reference behavior.  Likewise, provide a configure option
to disable the recently-committed float4 pass-by-value change.

Zoltan Boszormenyi, plus configurability stuff by me.

-1 to 1, not 0 to 1.  The actual behavior for values within this range
does not change.  Kris Jurka

values. The previous coding essentially assumed that x = sqrt(x*x), which
does not hold for x < 0.

Thanks to Jie Zhang at Greenplum and Gavin Sherry for reporting this
issue.

from the other string-category types; this eliminates a lot of surprising
interpretations that the parser could formerly make when there was no directly
applicable operator.

Create a general mechanism that supports casts to and from the standard string
types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's
I/O functions.  These new casts are assignment-only in the to-string direction,
explicit-only in the other, and therefore should create no surprising behavior.
Remove a bunch of thereby-obsoleted datatype-specific casting functions.

The "general mechanism" is a new expression node type CoerceViaIO that can
actually convert between *any* two datatypes if their external text
representations are compatible.  This is more general than needed for the
immediate feature, but might be useful in plpgsql or other places in future.

This commit does nothing about the issue that applying the concatenation
operator || to non-text types will now fail, often with strange error messages
due to misinterpreting the operator as array concatenation.  Since it often
(not always) worked before, we should either make it succeed or at least give
a more user-friendly error; but details are still under debate.

Peter Eisentraut and Tom Lane

Get rid of VARATT_SIZE and VARATT_DATA, which were simply redundant with
VARSIZE and VARDATA, and as a consequence almost no code was using the
longer names.  Rename the length fields of struct varlena and various
derived structures to catch anyplace that was accessing them directly;
and clean up various places so caught.  In itself this patch doesn't
change any behavior at all, but it is necessary infrastructure if we hope
to play any games with the representation of varlena headers.
Greg Stark and Tom Lane

pgsql-patches discussion of September 20, 2006. Bump the catversion.

The implementation is somewhat ugly logic-wise, but I don't see an
easy way to make it more concise.

When writing this, I noticed that my previous implementation of
width_bucket() doesn't handle NaN correctly:

    postgres=# select width_bucket('NaN', 1, 5, 5);
     width_bucket
    --------------
                6
    (1 row)

AFAICS SQL:2003 does not define a NaN value, so it doesn't address how
width_bucket() should behave here. The patch changes width_bucket() so
that ereport(ERROR) is raised if NaN is specified for the operand or the
lower or upper bounds to width_bucket(). For float8, NaN is disallowed
for any of the floating-point inputs, and +/- infinity is disallowed
for the histogram bounds (but allowed for the operand).

Update docs and regression tests, bump the catversion.

Improve release docs for ecpg regression tests.

like my HPPA ...

back-stamped for this.

Stefan Kaltenbrunner

document why this happens.  Remove exp() errno check because not needed.

only return Nan and set errno for pow/exp overflow/underflow.

platforms set errno, and we already have a check macro that detects
under/overflow, so there is no reason for platform-specific code
anymore.

isinf(), fall through to our own infinity checks.

infrastructure.

valid result from a computation if one of the input values was infinity.
The previous code assumed an operation that returned infinity was an
overflow.

Handle underflow/overflow consistently, and add checks for aggregate
overflow.

Consistently prevent Inf/Nan from being cast to integer data types.

Fix INT_MIN % -1 to prevent overflow.

Update regression results for new error text.

Per report from Roman Kononov.

proposed patches from John Jorgensen and Steve Singer.

the float8 versions of the aggregates, which is all that the standard requires.
Sergey's original patch also provided versions using numeric arithmetic,
but given the size and slowness of the code, I doubt we ought to include
those in core.

have no other gods before c.h'.  Also remove some demonstrably redundant
#include lines, mostly of <errno.h> which was added to c.h years ago.

	o  remove many WIN32_CLIENT_ONLY defines
	o  add WIN32_ONLY_COMPILER define
	o  add 3rd argument to open() for portability
	o  add include/port/win32_msvc directory for
	   system includes

Magnus Hagander

accuracy expected by the regression tests.  Per suggestion from
Martijn van Oosterhout.

similar constants if they were not previously defined. All these
constants must be defined by limits.h according to C89, so we can
safely assume they are present.

var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp()
are just renamings of the historical Postgres aggregates variance() and
stddev() -- the latter names have been kept for backward compatibility.
This patch includes updates for the documentation and regression tests.
The catversion has been bumped.

NB: SQL2003 requires that DISTINCT not be specified for any of these
aggregates. Per discussion on -patches, I have NOT implemented this
restriction: if the user asks for stddev(DISTINCT x), presumably they
know what they are doing.