Re: [BUGS] pgtcl large object fix
Mahlon Stacy <[EMAIL PROTECTED]> writes: > Newer versions of TCL implement ByteArray objects which are > the best fit for Postgresql Large Object functions. How newer is "newer"? That is, what compatibility problems might we create if we make this change? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] range query with timestamp returns different result with index than without (7.3.3)
Hi, I'm have the following query: select count(*) from delivery where "creation_date" <= TIMESTAMP '2003-04-01 00:00:00' and "creation_date" > TIMESTAMP '2003-03-01 00:00:00'; without any index the range query returns the correct result namely 272394, when i create an index on creation_date, I get 10371 as a result. I'm using 7.3.3 on Linux (gentoo). Any help appreciated, if you need more information I'm happy to provide it. Here is a transcript: gaiaperformance=> select count(*) from delivery where "creation_date" <= TIMESTAMP '2003-04-01 00:00:00' and "creation_date" > TIMESTAMP '2003-03-01 00:00:00'; count 272394 (1 row) gaiaperformance=> create index creation_date_ind on delivery (creation_date); CREATE INDEX gaiaperformance=> select count(*) from delivery where "creation_date" <= TIMESTAMP '2003-04-01 00:00:00' and "creation_date" > TIMESTAMP '2003-03-01 00:00:00'; count --- 10371 (1 row) christian -- Christian van der Leeden Logic United GmbH Tel: 089-189488-66 Mob: 0163-3747111 www.logicunited.com BEGIN:VCARD VERSION:3.0 N:van der Leeden;Christian;;; FN:Christian van der Leeden ORG:Logic United GmbH; TITLE:Software Engineering EMAIL;type=HOME;type=pref:[EMAIL PROTECTED] EMAIL;type=HOME:[EMAIL PROTECTED] TEL;type=WORK;type=pref:+49-89-189488-66 TEL;type=CELL:+49-163-3747111 ADR;type=WORK;type=pref:;;Brecherspitzstrasse 8;Muenchen;;81541;Germany URL:www.logicunited.com END:VCARD -- Christian van der Leeden Logic United GmbH Tel: 089-189488-66 Mob: 0163-3747111 www.logicunited.com BEGIN:VCARD VERSION:3.0 N:van der Leeden;Christian;;; FN:Christian van der Leeden ORG:Logic United GmbH; TITLE:Software Engineering EMAIL;type=HOME;type=pref:[EMAIL PROTECTED] EMAIL;type=HOME:[EMAIL PROTECTED] TEL;type=WORK;type=pref:+49-89-189488-66 TEL;type=CELL:+49-163-3747111 ADR;type=WORK;type=pref:;;Brecherspitzstrasse 8;Muenchen;;81541;Germany URL:www.logicunited.com END:VCARD ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Non-standard TIMESTAMP WITH TIME ZONE literal handling
On Thu, 7 Aug 2003, Troels Arvin wrote: > Hello, > > In Jim Melton and Alan Simon's "SQL:1999 - Understanding Relational > Language Components" (ISBN 1-55860-456-1), they write that the following > is to be interpreted as a TIMESTAMP WITH TIME ZONE value: > > TIMESTAMP '2003-07-29 13:19:30.5+02:00' > > PostgreSQL interprets the above as a TIMESTAMP WITHOUT TIME ZONE value of > '2003-07-29 13:19:30.5', i.e. it simply discards the '+02:00' part and > fails to interpret it as being of TIMESTAMP WITH TIME ZONE type. > > Unless Melton+Simon are wrong, PostgreSQL is not completely following > SQL:1999 regarding TIMESTAMP-like literal parsing. I think they're correct and we're wrong: SQL92 5.3 Syntax rules: 17)The data type of a that does not specify is TIMESTAMP(P), where P is the number of digits in , if specified, and 0 otherwise. The data type of a that specifies is TIMESTAMP(P) WITH TIME ZONE, where P is the number of digits in , if specified, and 0 otherwise. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] pg 7.4beta1 doc bug: vacuum not updated
The output of the vacuum command on http://developer.postgresql.org/docs/postgres/sql-vacuum.html shows the output of the 7.3.x version. I noticed while browsing the cvs that the output has changed. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] UNION discards indentical rows in postgres 7.3.3
Hi Tom, this seems a serious bug: testdb=> testdb=> create table t1(a int, b text); CREATE TABLE testdb=> create table t2(a int, b text); CREATE TABLE testdb=> insert into t1 values(1,'pippo'); INSERT 7591667 1 testdb=> insert into t1 values(2,'pluto'); INSERT 7591668 1 testdb=> insert into t2 values(3,'paperino'); INSERT 7591669 1 testdb=> insert into t2 values(3,'paperino'); INSERT 7591670 1 select a,b from t1 union (select a,b from t2); a |b ---+-- 1 | pippo 2 | pluto 3 | paperino (3 rows) Wrong ! The query should return 4 rows. In other words i don't know why postgres performs the following query: select a,b from t1 union (select DISTINCT a,b from t2); instead of the required one. I think i's a bug. Thank you. Silvio Scarpati ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
