Notice how the INT4 rounding is banker's rounding (round to the nearest even
number). That is what we would want the INT8 to do as well, not just a
simple round like I mentioned before. Again, the INT8 shows truncation. I've
been looking around the source code, but I can't see where all this
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
>
> Seems the BIT type works in Java 7.1 beta now.
Has anything changed with boolean types in the backend then, as nothing has
been done on the JDBC side?
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > "Jos? Antonio Matute Calvo" wrote:
>
Hmmm, what's the performance issues with this? Is there going to be a problem
with very large LargeObject's?
Quoting "Paul M. Aoki" <[EMAIL PROTECTED]>:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Anyone able to fix this?
>
> here's a hack we've been using in-house (written by Jun Gabayan,
Quoting Barry Lind <[EMAIL PROTECTED]>:
> This is no longer a problem in 7.1. The bug here was the same one
> introduced by the wrong version of Gunner's bytearray pooling patch
> being applied. It was fixed in current sources by Peter commenting out
> the bytearray pooling.
That's what I thou
Alex Krohn <[EMAIL PROTECTED]> writes:
> [postgres@penguin pgsql]$ locale
> LANG=en_US
> LC_CTYPE="en_US"
> LC_NUMERIC="en_US"
> LC_TIME="en_US"
> LC_COLLATE="en_US"
> LC_MONETARY="en_US"
> LC_MESSAGES="en_US"
> LC_ALL=en_US
> [postgres@penguin pgsql]$
> Postmaster is running as user pgsql. Any i
Alex Krohn <[EMAIL PROTECTED]> writes:
>> Beware of changing the postmaster's locale on the fly, however,
>> since that will leave you with corrupted (out-of-order) indexes.
>> Safest to dump/initdb in new locale/reload.
> How would I go about changing that? Setting LANG and LC_ALL in the pgsql
>
I think this is fixed in 7.1beta.
> Alexander Dietrich ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> JDBC driver throws SQLException while parsing timestamp
>
> Long Description
> Hi,
>
> there's a discrepancy betwe
Alex Krohn <[EMAIL PROTECTED]> writes:
> So I added:
> LANG=C
> LC_ALL=C
> to the /etc/rc.d/init.d/postgres file and stop, restarted the server. I
> then dropped and recreated the database. However still same results.
LC_COLLATE overrides LC_ALL, I think --- didn't you previously show us
that al
>> The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety
>> floating-point roundoff error. However, I think Max has a fair
>> complaint here: it seems float-to-int8 conversion is truncating, not
>> rounding like the other conversions to integer do.
I have changed float8-to-int8
On Friday 26 January 2001 18:07, Tom Lane wrote:
> Curiously, this change exposed what I take to be a platform dependency
> in the int8 regress test. It was computing
> int8(float8(4567890123456789::int8)) and expecting to get back exactly
> 4567890123456789. However, that value is 53 bits long
Alex Krohn <[EMAIL PROTECTED]> writes:
> I added to the startup file:
> LANG=C
> LC_CTYPE=C
> LC_NUMERIC=C
> LC_TIME=C
> LC_COLLATE=C
> LC_MONETARY=C
> LC_MESSAGES=C
> LC_ALL=C
Seems reasonable. It's possible you needed "export" commands in there
too, but I wouldn't have thought so (anything com
This is no longer a problem in 7.1. The bug here was the same one
introduced by the wrong version of Gunner's bytearray pooling patch
being applied. It was fixed in current sources by Peter commenting out
the bytearray pooling.
thanks,
--Barry
Bruce Momjian wrote:
>
> Anyone fixing this bug?
Hi,
> Alex Krohn <[EMAIL PROTECTED]> writes:
> >> Beware of changing the postmaster's locale on the fly, however,
> >> since that will leave you with corrupted (out-of-order) indexes.
> >> Safest to dump/initdb in new locale/reload.
>
> > How would I go about changing that? Setting LANG and LC_A
Hi,
> > So I added:
> > LANG=C
> > LC_ALL=C
> > to the /etc/rc.d/init.d/postgres file and stop, restarted the server. I
> > then dropped and recreated the database. However still same results.
>
> LC_COLLATE overrides LC_ALL, I think --- didn't you previously show us
> that all the LC_xxx famil
Hi Tom,
> Alex Krohn <[EMAIL PROTECTED]> writes:
> > links=# select * from foo where a like 'Test/%'
> > links-# ;
> > a
> > ---
> > (0 rows)
>
> This looks like an artifact of the known problems with LIKE index
> optimization in non-ASCII locales. What
Your name : Michael Davis
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium 233 (2
processors)
Operating System (example: Linux 2.0.26 ELF) : Linux (Red Hat 6.2)
Postg
Hi Tom,
> > I added to the startup file:
> > LANG=C
> > LC_CTYPE=C
> > LC_NUMERIC=C
> > LC_TIME=C
> > LC_COLLATE=C
> > LC_MONETARY=C
> > LC_MESSAGES=C
> > LC_ALL=C
>
> Seems reasonable. It's possible you needed "export" commands in there
> too, but I wouldn't have thought so (anything coming in
Hi Tom,
> > [postgres@penguin pgsql]$ locale
> > LANG=en_US
> > LC_CTYPE="en_US"
> > LC_NUMERIC="en_US"
> > LC_TIME="en_US"
> > LC_COLLATE="en_US"
> > LC_MONETARY="en_US"
> > LC_MESSAGES="en_US"
> > LC_ALL=en_US
> > [postgres@penguin pgsql]$
>
> > Postmaster is running as user pgsql. Any ideas o
Peter T Mount <[EMAIL PROTECTED]> writes:
> Hmmm, what's the performance issues with this? Is there going to be a problem
> with very large LargeObject's?
you could probably be smarter about caching previous tell() state, if
that's what you mean.
jun's hack doesn't actually add any extra buffe
Alex Krohn <[EMAIL PROTECTED]> writes:
>> On my machine, these produce 't' in C locale, but 'f' in en_US locale.
> Seem to be in C locale:
So it does. Okay, what was the complete test case again?
I'm afraid I didn't save your original message because I wrote it off
as a known problem ...
Alex Krohn <[EMAIL PROTECTED]> writes:
>>> Seem to be in C locale:
>>
>> So it does. Okay, what was the complete test case again?
>> I'm afraid I didn't save your original message because I wrote it off
>> as a known problem ...
> Here it is:
> links=# create table foo ( a char(25) );
Alex Krohn <[EMAIL PROTECTED]> writes:
>> What does EXPLAIN VERBOSE select * from foo where a like 'Test/%';
>> show?
Well, the indexqual is just what it should be for C locale:
:indxqual ((
{ EXPR :typeOid 16 :opType op :oper
{ OPER :opno 1061 :opid 1052 :opresulttype 16 } :args (
{ VAR :varn
> Is postgres going to use the scientific method of rounding or just
> the simple one? Or even make it configurable. As I recall, the
> scientific method says that 4.5 should be rounded to 4 and 5.5 should
> be rounded to 6. The idea was that even numbers were easier to work
> with and roundin
Michael Davis <[EMAIL PROTECTED]> writes:
> Is there a bug with importing from a pg_dump file and foreign keys? If I
> create two tables where one table has a foreign key relationship to the
> other and look at the system tables everything looks great. If I then
> pg_dump, dropdb, createdb, a
24 matches
Mail list logo
