Jacek Smyda ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Incorrect parse with time function
Long Description
Parser error with function time (ver. 7.2). See example.
Sample Code
SELECT time('10:10');
Output:
ERROR: parser
(Dunno if my previous got sent or not since I wasn't subscribed)
Hi,
When creating a table from psql named 'tblProduct' that is turned into
tblproduct. (I'm accessing pg through Qt db classes too and I experience
the same thing there too I believe)
However, when creating a table with the tcl/tk
Hi
I am using PostgreSQL version 7.1.2
and the problem that I am facing can be reproduced as below
create table numeric_tab (col1 numeric(20)) ;
CREATE
insert into numeric_tab values(123456789012345) ;
INSERT 95 1
select col1 from numeric_tab where col1 = 123456789012345 ;
ERROR: Unable to
Hi,
We have a table named "atm" in
our database which is uing latest driver of postgresql, it has a column named
"location", all records (which are more than 1) of "atm"
table have this column value set as (null). When we executed the query "select
* from atm where location=null ", 0
SQL uses tri-state logic. If any value in an expression is unknown, the
answer is unknown. The only time you can get a true or false result
from an expression is if all values are known. In SQL, null represents
an unknown value - it does not represent an empty value (such as a zero
length strin
On Thu, 14 Mar 2002, awais wrote:
> Hi,
>
> We have a table named "atm" in our database which is uing latest
> driver of postgresql, it has a column named "location", all records
> (which are more than 1) of "atm" table have this column value set as
> (null). When we executed the query "sele
Torsten Krämer ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Bug in ilke and ~~* Sql expression
Long Description
i tried to do a select on some columns case insensitive.
some charachters like äöü.. the ilike,~~*,upper made mi
> AFAICS the only way that we could make the one-WAL-record-every-32-
> nextvals idea really work would be if CHECKPOINT could nullify the
> logged-in-advance state of each sequence (so that the first nextval
> after a checkpoint would always generate a fresh WAL record, but
> subsequent ones woul
> > It seems safe to do NOT write WAL record if sequence
> > LSN > system RedoRecPtr because of checkpoint started after our
> > check would finish only after writing to disk sequence buffer with
> > proper last_value and log_cnt (nextval keeps lock on
> > sequence buffer).
>
> Mmm ... maybe. I
I don't fully understand the xlog files or WAL records but...
Why isn't the writing of the WAL record based on the CACHE value of the
sequence? If a request to nextval() can't be satisfied by the cache,
the sequence on disk should be updated resulting in a WAL record being
written.
If two sessi
On Thu, 14 Mar 2002, Tom Pfau wrote:
> I don't fully understand the xlog files or WAL records but...
>
> Why isn't the writing of the WAL record based on the CACHE value of the
> sequence? If a request to nextval() can't be satisfied by the cache,
> the sequence on disk should be updated result
"Tom Pfau" <[EMAIL PROTECTED]> writes:
> I'm concerned that the discussion here has been of the opinion that
> since no records were written to the database using the value retrieved
> from the sequence that no damage has been done.
Um, you certainly didn't hear me saying that ;-)
There are two
[EMAIL PROTECTED] writes:
> i tried to do a select on some columns case insensitive.
> some charachters like äöü.. the ilike,~~*,upper made mistakes
Sounds like you didn't initialize the database with the right locale
setting.
regards, tom lane
--
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
> Stephan, let me know if you want this consid
"Dave Cramer" <[EMAIL PROTECTED]> writes:
> I noticed a message asking if this scenario was consistent with the
> other reports, and yes it is. We have seen this occuring on our system
> with versions as old as 7.0.
Given that these are WAL bugs, they could not predate 7.1.
On Thu, 14 Mar 2002, Tom Lane wrote:
>
> If you do a SELECT nextval() and then use the returned value externally
> *without waiting for a commit acknowledgement*, then I think you are
> risking trouble; there's no guarantee that the WAL record (if one is
> needed) has hit disk yet, and so a crash
Ben Grimm <[EMAIL PROTECTED]> writes:
> The behavior of SELECT nextval() should not be conditional on being in or
> out of a transaction block.
Nonsense. The behavior of INSERT or UPDATE is "conditional" in exactly
the same way: you should not rely on the reported result until it's
committed.
On Thu, 14 Mar 2002, Mikheev, Vadim wrote:
> And it's not. But behaviour of application *must* be
> conditional on was transaction committed or not.
>
> What's the problem for application that need nextval() for
> external (out-of-database) purposes to use sequence values
> only after transactio
18 matches
Mail list logo
