On Wed, May 12, 2010 at 2:44 AM, Tom Lane wrote:
> I think what you are describing is a kernel bug. There's not a lot
> we can do about it if the send() call hangs. Considering the kernel
> already knows the connection is closed (per the CLOSE_WAIT state shown
> by netstat) the send() should ret
Tom Lane wrote:
Matthew Nourse writes:
As NOT NULL on domains doesn't always prevent a value from becoming NULL
(and because it "sucks" :) ) would you consider deprecating the
not-null-on-domains feature and then removing it from some future
version of PostgreSQL?
We can't really because it
Matthew Nourse writes:
> As NOT NULL on domains doesn't always prevent a value from becoming NULL
> (and because it "sucks" :) ) would you consider deprecating the
> not-null-on-domains feature and then removing it from some future
> version of PostgreSQL?
We can't really because it's required
"Sergey" writes:
> 8849.15+6464.57=15313.72
> But sum()=15313.7
You did not show what datatype you're summing, but if the column is
float4 this result wouldn't be surprising. float4 is only good
to about six decimal digits.
regards, tom lane
--
Sent via pgsql-bugs mail
On Sun, May 30, 2010 at 4:45 AM, Robert Haas wrote:
> On Sat, May 29, 2010 at 5:00 PM, Bruce Momjian wrote:
>> I have updated the patch, attached, to clarify that this returns text
>> arrays, and that you can force it to always return one row using
>> COALESCE() and a '|' pattern (the later sugge
The following bug has been logged online:
Bug reference: 5484
Logged by: Sergey
Email address: vi...@yandex.ru
PostgreSQL version: 8.4.4
Operating system: FreeBSD 7.3
Description:sum() bug
Details:
Function sum() bug.
8849.15+6464.57=15313.72
But sum()=15313.7
[r..
Kevin Grittner wrote:
Tom Lane wrote:
< NOT NULL constraints at the domain level suck. Don't use 'em.
+1
As someone who uses domains very heavily, I can attest that the
semantics of that are very weak. Whether a domain is nullable
depends almost entirely on the context of its use, which
