"Rainer Mager" <[EMAIL PROTECTED]> writes:
> The Postgres docs mention the the precision/range of timestamp with and
> withount a timezone is different.
Where are you reading that, exactly? Since there isn't any difference
between "timestamp with and without a timezone", that can't possibly be
w
Thanks for the info. I'm unsure on a few things, though.
The Postgres docs mention the the precision/range of timestamp with and
withount a timezone is different. Are you saying that, because they are,
internally, the same the precision/range is also the same?
Also, we have seen a bug regarding
[EMAIL PROTECTED] writes:
> The functions Lower amd Upper doesn't work with cyrillic, but
> works fine with latin (a-z A-Z).
upper/lowercase conversions are driven by LOCALE setting, not
by multibyte character set. As far as I can tell, you have not
done anything to select a cyrillic locale.
Dmitry Bezgodov ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Upper(), Lower() bug
Long Description
The functions Lower amd Upper doesn't work with cyrillic, but
works fine with latin (a-z A-Z).
Tested on psql (PostgreSQL) 7
Achim =?iso-8859-1?Q?Kr=FCmmel?= <[EMAIL PROTECTED]> writes:
> when using "vacuum analyze " on very large tables (I have one
> with about 30GB) the memory usage increases continues until no memory is
> left and the kernel stops this process.
I don't have 30Gb to spare, but I set up a table of the
David Daney ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
JDBC driver security issue.
Long Description
The JDBC driver requires
permission java.lang.RuntimePermission "shutdownHooks";
in the policy file in order to func
dave miller ([EMAIL PROTECTED]) reports a bug with a severity of 1
The lower the number the more severe it is.
Short Description
unable to do selects on certain fields in large tables
Long Description
In a table of about 300 MG, I am unable browse or select the text field - xml (holding
a large
> Rainer Mager ([EMAIL PROTECTED]) reports a bug with a severity of 2
> Creating a TABLE with a TIMESTAMP type seems to ignore the WITH TIME
> ZONE option. That is, with or without the option the TIMESTAMP still
> has a time zone.
We feel that the SQL timestamp definition as regards with/without
test ([EMAIL PROTECTED]) reports a bug with a severity of 4
The lower the number the more severe it is.
Short Description
testing the subject and header changes
Long Description
testing
Sample Code
No file was uploaded with this report
---(end of broadcast)--
