[EMAIL PROTECTED] writes:
> SELECT * FROM Noticia WHERE data >= CURRENT_DATE - 10
> and returns: Unable to convert data to tm.
Curious. This seems to indicate that mktime() is failing, which
as far as I can see it should not do. Is 13/10/2002 a daylight-savings
transition day in your timezone?
Kristian Lance <[EMAIL PROTECTED]> writes:
> This message is a follow up to this thread:
> http://archives.postgresql.org/pgsql-bugs/2001-12/msg8.php
> I finally got a chance to rebuild the DB server using C locale, and it made
> no difference to my ORDER BY problem. PostgreSQL did not disti
Osmar Junior Klock ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Problem with timestamp conversion
Long Description
I tried
SELECT * FROM Noticia WHERE data >= CURRENT_DATE - 10
and returns: Unable to convert data to tm.
Howe
This message is a follow up to this thread:
http://archives.postgresql.org/pgsql-bugs/2001-12/msg8.php
I finally got a chance to rebuild the DB server using C locale, and it made
no difference to my ORDER BY problem. PostgreSQL did not distinguish
between slashes, dashes, and spaces when s
Arne Woerner <[EMAIL PROTECTED]> writes:
> Is this bug fixed in 7.2.3?
Try it and see.
FWIW, on HPUX with current CVS tip I could not measure any difference in
performance between a single client issuing INSERTs like yours and ten
clients doing so: I got essentially the same number of insertions/
Nicolaus Erichsen <[EMAIL PROTECTED]> writes:
> pg_dump forgets to include the 'with encoding ' statement in its ouput.
Fixed since 7.2.1.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Nicolaus Erichsen <[EMAIL PROTECTED]> writes:
> I recently found a problem with sorting german 'Umlaute' .
Sounds like you did not set the right locale when creating the database.
You need to be careful to run initdb with LANG (or LC_ALL or at least
LC_COLLATE) set to what you want, probably "de_D
Yes, this is a known issue with now(). We discussed it at great length
and decided to keep it the same in 7.3. There is timeofday for
current time, but that can change during the query. I think 7.4 will
have a parameter to now() which you can get the statement time, which is
probably what you w
On Tue, 22 Oct 2002, Sedlak Anton wrote:
> Because author is not responding I'm writing to you.
> In contrib/chkpass.c there is no checking against NULL values on input,
> thus if you call eg. raw(NULL) then postgresql always dies.
> Although storing encrypted password are highly required this beh
On Sun, 20 Oct 2002, geva wrote:
>
> i'm encountering an recurring problem in which running vacuum on a
> relatively large
> database ( >3 rows) causes the database to corrupt rather badly. all
> subsequent calls to vacuum does not return, and the only solution is to
> pg_dump the
On Wed, 16 Oct 2002, Talja Ari wrote:
> Postgres version: 7.2.1
> Platform: Server on Linux, (java-)client on HP-UX.11 and SunOS 5.8
> JDBC drivers: For PostgreSQL 7.2, JDK 1.3
> JDK version: 1.3.1
> Autocommit off for each connection
> Special server flags: -i to allow the connections from differ
Hi!
I tried to insert values into a table (created by
CREATE TABLE gaga42 (a bigint, b char varying);
) (inserted by
insert into gaga42 values (0,X);
(where X varies between '' and '1...1' (1000 chars))
). I used the standard configuration of PostgreSQL 7.1.3 on a OpenBSD 3
Because author is not responding I'm writing to you.
In contrib/chkpass.c there is no checking against NULL values on input,
thus if you call eg. raw(NULL) then postgresql always dies.
Although storing encrypted password are highly required this behavior
makes this extension module unusable.
To
Hello everybody,
pg_dump forgets to include the 'with encoding ' statement in its ouput.
To reproduce:
- snip
nico@nico:~> psql -Upostgres -dtemplate1
Welcome to psql, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
At last I decided to post my problem here: I have a web application
running since one year on postgres 7.1.3 with good performance. Now
suddenly a query takes huge amounts of time: I tried to turn of
SEQ_SCAN, and it was fast again.
The following Query needs about 0,2 seconds with SEQ_SCAN set to
i'm encountering an recurring problem in which running vacuum on a
relatively large
database ( >3 rows) causes the database to corrupt rather badly. all
subsequent calls to vacuum does not return, and the only solution is to
pg_dump the database, drop all or some of the tables, and
Hello everybody,
I recently found a problem with sorting german 'Umlaute' . I hope the encoding
of this mail works ;-) :
Postgres puts Umlaute (i.e., ÄäÖöÜü) at the very end of the Alphabet, and
this is not the way it should be. I didn't check for the special Character
'ß', but its probably
Postgres version: 7.2.1
Platform: Server on Linux, (java-)client on HP-UX.11 and SunOS 5.8
JDBC drivers: For PostgreSQL 7.2, JDK 1.3
JDK version: 1.3.1
Autocommit off for each connection
Special server flags: -i to allow the connections from different host
The program is a java server, which updat
18 matches
Mail list logo
