Dana Hudes wrote:
> The documentation clearly states in section "1.1.1 Identifiers and
> Keywords" that "Identifier and key word names are case insensitive".
> It goes on to give an example where a column name is used in lower
> case and in upper case or any mixture.
>
> I have found that the actua
Pavel Stehule wrote:
> its not error. Only SQL specific :-) NULL <> NULL
Au contraire, neither
NULL = NULL
nor
NULL <> NULL
is true.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
The documentation clearly states in section "1.1.1 Identifiers and
Keywords" that "Identifier and key word names are case insensitive".
It goes on to give an example where a column name is used in lower case
and in upper case or any mixture.
I have found that the actual implemented behavior is no
Hello,
its not error. Only SQL specific :-) NULL <> NULL
Regards
Pavel Stehule
On Tue, 6 Jul 2004, David Newall wrote:
> PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
>
> Operating Sysem: Fedora Core 1
>
> CREATE TABLE t1 (i INTEGER, j INTEGER);
> INSERT INTO t1 VALUES (1, NULL
On Tue, 6 Jul 2004, David Newall wrote:
> PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
>
> Operating Sysem: Fedora Core 1
>
> CREATE TABLE t(i integer UNIQUE);
> INSERT INTO t VALUES (null);
> INSERT INTO t VALUES (null);
> SELECT coalesce(i,-999) FROM t;
> coalesce
> --
>
On Tue, 6 Jul 2004, David Newall wrote:
> PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
>
> Operating Sysem: Fedora Core 1
>
> CREATE TABLE t1 (i INTEGER, j INTEGER);
> INSERT INTO t1 VALUES (1, NULL);
> CREATE TABLE t2 AS SELECT * FROM t1;
> SELECT * FROM t1 JOIN t2 USING (i, j);
David Newall wrote:
> PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
>
> Operating Sysem: Fedora Core 1
>
> CREATE TABLE t1 (i INTEGER, j INTEGER);
> INSERT INTO t1 VALUES (1, NULL);
> CREATE TABLE t2 AS SELECT * FROM t1;
> SELECT * FROM t1 JOIN t2 USING (i, j);
> i | j
> ---+---
> (
David Newall wrote:
> PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
>
> Operating Sysem: Fedora Core 1
>
> CREATE TABLE t(i integer UNIQUE);
> INSERT INTO t VALUES (null);
> INSERT INTO t VALUES (null);
> SELECT coalesce(i,-999) FROM t;
> coalesce
> --
> -999
> -99
kris,
Next you can see how the same test-case is handled by DB2.
-- IBM DB2 V6.1 for Linux
CREATE TABLE userid.t (
f1 numeric(6,3),
f2 numeric(6,4),
f3 numeric(8,2)
);
create view userid.v as
select
(f1+f2+f3) as fsum,
coalesce(f1,f2,f3) as fcoal,
(f1*f2*f3) as fprod,
(f1/f2) as fdiv
PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
Operating Sysem: Fedora Core 1
CREATE TABLE t(i integer UNIQUE);
INSERT INTO t VALUES (null);
INSERT INTO t VALUES (null);
SELECT coalesce(i,-999) FROM t;
coalesce
--
-999
-999
(2 rows)
---(
PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
Operating Sysem: Fedora Core 1
CREATE TABLE t1 (i INTEGER, j INTEGER);
INSERT INTO t1 VALUES (1, NULL);
CREATE TABLE t2 AS SELECT * FROM t1;
SELECT * FROM t1 JOIN t2 USING (i, j);
i | j
---+---
(0 rows)
I believe the one row, which is
I have found that the problem is worst.
In the sample adjunct, you can see that error arise at the time when
the view's sql text is parsed and saved in database catalog.
Then generic NUMERIC type is forced for every calculated column without
regard or precision.
And at execute time the f2 colu
PostgreSQL version: 7.4.3 (RPMs from ftp.au.postgresql.org)
Operating Sysem: Fedora Core 1
GIVEN
CREATE TABLE data (i integer);
AND
SELECT count(*), min(i), max(i) FROM data;
count | min | max
---+-+-
1340 | 3 | 20
(1 row)
(Actual data attached as data.dmp)
NOW CONSIDER
Stephan Szabo wrote:
On Sun, 4 Jul 2004, Kris Jurka wrote:
On Sat, 3 Jul 2004, Dario V. Fassi wrote:
In the sample adjunct, you can see that error arise at the time when the
view's sql text is parsed and saved in database catalog.
Then generic NUMERIC type is fo
Stephan, look at the samples I send in previous posts , from PgSql and
Db2.
I know it's a no ease task to change all that behavior , but you must
agree that a Numeric column with the fractional part varing from row to
row are different data types and break relational rules.
If this is the case
The following bug has been logged online:
Bug reference: 1189
Logged by: George Gal
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: FreeBSD 5.2 (Current)
Description:unbounded string copy in postmaster
Details:
Looks like the -o comm
On Wed, 7 Jul 2004, Peter Eisentraut wrote:
> Am Mittwoch, 7. Juli 2004 14:58 schrieb PostgreSQL Bugs List:
> > Description:evaluation order of select seems to be wrong
>
> Please read this:
> http://www.postgresql.org/docs/7.4/static/sql-expressions.html#SYNTAX-EXPRESS-EVAL
The issue is
Am Mittwoch, 7. Juli 2004 14:58 schrieb PostgreSQL Bugs List:
> Description:evaluation order of select seems to be wrong
Please read this:
http://www.postgresql.org/docs/7.4/static/sql-expressions.html#SYNTAX-EXPRESS-EVAL
---(end of broadcast)-
The following bug has been logged online:
Bug reference: 1188
Logged by: Holger Jakobs
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux
Description:evaluation order of select seems to be wrong
Details:
There is a table like
cr
19 matches
Mail list logo
