postgresql version = 7.1
platform = linux intel
Hi. I guess this isn't really a bug since it's acknowledged by the docs
in auth-methods.html:
'Alternative passwords cannot be used when using the crypt method. The
file will still be evaluated as usual but the password field will simply
be ignor
> SQL92 says
>
> Whether a sort key value that is null is considered greater
> or less than a non-null value is implementation-defined, but
> all sort key values that are null shall either be considered
> greater than all non-null values or
Your name :
Your email address :
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium
Operating System (example: Linux 2.0.26 ELF) : Solaris 8, Linux
(various versions)
Pos
> Automatically thinks that the last value is a US style date.
> Date style is set to EURO, but I assume this has no affect on the date
> parsing at insert time.
Yes it does, for ambiguous cases such as yours.
> If the dates are entered as 'ccyy.mm.dd' it is okay - unfortunately all my
> dates a
Hi,
I've discovered a bug in Postgres. When you rename
a table, the corresponding triggers for that table
are not updated.
For example:
CREATE TABLE tblParent (
ID SERIAL NOT NULL,
Name text,
PRIMARY KEY (ID)
);
CREATE TABLE tblChild (
ID int4 NOT NULL,
email text,
FOREIGN KEY
7.0.x okay, 7.1 incorrect (CVS from 24th April):
create table test(aaa date);
insert into test(aaa) values ('23.10.1997');
insert into test(aaa) values ('13.10.1997');
insert into test(aaa) values ('2.10.1997');
select * from test;
gives:
a
1997-10-23
1997-10-13
1997-2-10
Automati
Hi,
Here are the maximum information about the error:
OS where the class is running: winnt4 with jdk1.3
DB OS: Linux Debian potatoe
Postgresql version: 7.0.3
Driver JDBC: included in the source code.
Description:
---
First case (postmaster is running ok):
I get the connection with:
co
[EMAIL PROTECTED] writes:
> Optimalisation options change query results
SQL92 says
Whether a sort key value that is null is considered greater
or less than a non-null value is implementation-defined, but
all sort key values that are null shall either be
wolfgang ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Input/Output of byte[]-Fields with 'FF' values in LargeObject with JDBC
Long Description
The following Java-Code don't work because of the "0xff" values
in the byteField:
Marcin Zukowski ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Optimalisation options change query results
Long Description
I had a problem with retrieving data when some of the multi-column index fields were
NULL - it was al
7.0.x okay, 7.1 incorrect (CVS from 24th April):
create table test(aaa date);
insert into test(aaa) values ('23.10.1997');
insert into test(aaa) values ('13.10.1997');
insert into test(aaa) values ('2.10.1997');
select * from test;
gives:
a
1997-10-23
1997-10-13
1997-2-10
Automati
11 matches
Mail list logo
