[BUGS] BUG #7653: Minor problem with join condition
The following bug has been logged on the website: Bug reference: 7653 Logged by: Stefano Baccianella Email address: stef...@sportilia.com PostgreSQL version: 9.2.1 Operating system: Linux CentOS Description: Don't know if this is a bug or a correct behaviour, but in a query like this: SELECT t1.* FROM table1 t1 JOIN table2 t2 ON t1.id = t2.t1id JOIN table3 t3 ON t1.id = t2.t1id The parser should return an error because we are joining a table without using any of its column. I know this is a minor issue and a correct SQL syntax, but logically a JOIN without condition is a Cartesian product between the two tables and not a JOIN. My proposal is to raise an error when a join condition doesn't contains the table reference. Regards -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4749: trigonometric functions broken
The following bug has been logged online: Bug reference: 4749 Logged by: Stefano Salvador Email address: stefano.salva...@gmail.com PostgreSQL version: 8.3.7 Operating system: Linux Description:trigonometric functions broken Details: try: select sin(pi()); returns: 1.2246 or: select cos(pi()/2); returns: 6.123 but sin and cos are limited between -1 and 1 !!! I suspect than tan() function is broken too. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug #616: Alter table add foreign key
At 07.24 15/03/02 -0500, you wrote:
>I tried to execute following SQL alter table PRICEGROUP add FOREIGN
>KEY ("PARENT") REFERENCES "PRICEGROUP" ON DELETE CASCADE
>
>this gives an error ALTER TABLE: column "PARENT" referenced in foreign key
>constraint does not exist (7) while I'm sure that the column exists and is
>Non null. I'm using version 7.2 on linux redhat 7.2
Hello Dirk,
if you are using double quotes around the column name the name won't be
translated in lowercase; maybe the column name wasn't created this way and
that's why you caon't find it. Try to
alter table pricegroup add foreign key (parent) references pricegroup on
delete cascade
without using double quotes.
Just my 0.02
Ciao,
Stefano
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1063: tcp/ip
i've this problem but on windowsxp.. how i can resolve? "PostgreSQL Bugs List" wrote: > The following bug has been logged online: > > Bug reference: 1063 > Logged by: forty > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 7.4 > > Operating system: windows me > > Description:tcp/ip > > Details: > > > > PSQL.EXE: could not connect to server: Socket error, no > description available (0X2740) > Is the server running on host localhost and accepting > TCP/IP connection on port 5432? > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1063: tcp/ip
i've the postgres 8.2 2007/5/6, Heikki Linnakangas <[EMAIL PROTECTED]>: Stefano T wrote: > i've this problem but on windowsxp.. how i can resolve? First of all, PostgreSQL 7.4 on Windows isn't officially supported. Please upgrade to 8.2. >> Is the server running on host localhost and accepting >> TCP/IP connection on port 5432? Well, is it? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Stefano
[BUGS] PostgreSQL 8 Installed on Windows
Hi, I've installed successfully PostgreSQL on Windows XP. PostgreSQL is installed on user postgresql, with non administrative permission. I try to use "createdb" to create a mydb but I'm not able to archive the operation with success. Error message (on a DOS prompt window) is the following: C:\Programmi\PostgreSQL\8.0.0-beta4\bin>createdb mydb Password: createdb: could not connect to database template1: FATAL: password authenticati on failed for user "postgresql" What can I do? Kind regard. Tanks in advance for the help. Stefano Tazzi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Bug on CHARACTER(n) ?
Hello list,
maybe I am missing something. Look at this:
CREATE TABLE test (name character(10));
INSERT INTO test VALUES ('test');
SELECT '<' || name || '>' FROM test;
?column?
--
SELECT length(name), name from test;
length |name
+
4 | test
Should not a char(10) insert 6 padding spaces? Or am I missing something
like an update in the SQL standard?
Sorry if this is an already known issue, I had no time lately to check the
bugs mailing list.
Ciao,
Stefano
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[BUGS] BUG #6512: Bug with prepared statement and timestamp + interval
The following bug has been logged on the website: Bug reference: 6512 Logged by: Stefano Baccianella Email address: stefano.bacciane...@gmail.com PostgreSQL version: 9.1.1 Operating system: Windows 7 64bit Description: When trying to execute a query like: SELECT * FROM table WHERE timestamp_column > $1 AND timestamp_column < $1 + interval '1 hour' There is no problems, but when executing SELECT * FROM table WHERE timestamp_column > $1 - interval '1 hour' AND timestamp_column < $1 + interval '1 hour' The database return a error saying the the operator timestamp > interval does not exist. Either the query SELECT * FROM table WHERE timestamp_column < $1 + interval '1 hour' AND timestamp_column > $1 Does not work The $1 value is a timestamp (like now() for instance). But the query SELECT * FROM table WHERE timestamp_column = $1 OR ( timestamp_column > $1 - interval '1 hour' AND timestamp_column < $1 + interval '1 hour') works as expected. It seems that the analyzer cannot guess the value of a prepared statement combined with an interval. For my test i'm using PHP without PDO. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6512: Bug with prepared statement and timestamp + interval
I think that the problem is on the type inference algorithm. Starting from: typeof(X) = timestamp typeof(Y) = ? typeof(Z) = interval typeof(Y op Z) = ? [timestamp/interval] The inference algorithm starts from the right X > Y + Z => X > ? + interval [here the algorithm has two choices, timestamp or interval, he chooses interval] timestamp + interval => error but starting from the left side: X > Y + Z => timestamp > Y + Z [the only way to resolve the inference is to assign the type timestamp to Y + Z and resolve the type of Y to timestamp] timestamp > timestamp + interval => timestamp > timestamp => timestamp I don't know if this is a design choice or a side effect, probably the first. --- Stefano 2012/3/12 Robert Haas > On Sat, Mar 3, 2012 at 7:47 PM, wrote: > > The following bug has been logged on the website: > > > > Bug reference: 6512 > > Logged by: Stefano Baccianella > > Email address: stefano.bacciane...@gmail.com > > PostgreSQL version: 9.1.1 > > Operating system: Windows 7 64bit > > Description: > > > > When trying to execute a query like: > > > > SELECT * FROM table WHERE > > timestamp_column > $1 > > AND timestamp_column < $1 + interval '1 hour' > > > > There is no problems, but when executing > > > > SELECT * FROM table WHERE > > timestamp_column > $1 - interval '1 hour' > > AND timestamp_column < $1 + interval '1 hour' > > > > The database return a error saying the the operator timestamp > interval > > does not exist. > > This appears to be a type resolution problem. I find that it doesn't > matter whether I compare timestamp_column to $1 using > or <, nor does > it matter whether I use + to add an interval or - to subtract one. > However, if the first reference to $1 in the query is a direct > comparison against timestamp_column, then everything is fine; if the > first reference involves additional or subtraction of an interval, > then it breaks. > > Here's what I think is happening: when PostgreSQL sees $1 + interval > '1 hour' first, it concludes that $1 must be intended to be an > interval, so that $1 + interval '1 hour' is also an interval, and that > can't be compared to the timestamp column, so it errors out. But when > it sees timestamp_column > $1 first, it concludes that $1 must be > intended to be a timestamp. After that, when it subsequently sees $1 > + interval '1 hour', it's already decided that $1 is a timestamp, so > it uses the timestamp + interval operator here rather than interval + > interval; that yields a timestamp, so everything's fine. > > The right fix here is probably to explicitly specify the types you > want for the parameters, rather than making PostgreSQL guess. That > is, instead of saying: > > PREPARE x AS SELECT * FROM foo WHERE timestamp_column > $1 - interval > '1 hour' AND timestamp_column < $1 + interval '1 hour' > > Instead do: > > PREPARE x (timestamp) AS SELECT * FROM foo WHERE timestamp_column > $1 > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
