DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
	b=kIBEZ4I9t+EoGW/WtPCnTMZubxDsy/QQf837q05wqjEsyzFAVNPbL/RVKZK4aST6UHdopltLeN7eO+890zfUby151FLz50Rou83qyghInlWqTn2ic0Pd6I3Zp5Lz46AOL3TBF0ivBjYQnada0GIE76iJCQmnoDgAHQMCIQxiEhE=
Message-ID: <42931629.6030103@gmail.com>
Date: Tue, 24 May 2005 13:55:21 +0200
From: =?UTF-8?B?U3rFsWNzIEfDoWJvcg==?= <surrano@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: "pgsql-sql@postgresql.org" <pgsql-sql@postgresql.org>,
	"pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Subject: Re: [SQL] could not devise a query plan
References: <05d801c41bd8$daf4f8f0$0403a8c0@fejleszt4>
	<E25DB61B3C8.0000001Fs.gnanavel@inbox.com>
In-Reply-To: <E25DB61B3C8.0000001Fs.gnanavel@inbox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear Gnanavel,

(please reply to the lists...)

Indeed it works!

Still, I think it's a bug.

As for this solution being a workaround, it's a bit of pain, since the 
subselect names (effectively, the included subselects) are not constant.

As for my workaround, I used a condition to not include the last WHERE 
clause in the query when the inner WHERE clauses are present (since it does 
nothing).

--
G.


On 2005.05.24. 13:14, Gnanavel Shanmugam wrote:
> replace
>  WHERE a+b = 3;
> with
>  WHERE aa.a+aa.b = 3;
> 
> (or)
>  WHERE bb.a+bb.b = 3;
> 
> 
> with regards,
> S.Gnanavel
> 
> 
> 
>>-----Original Message-----
>>From: surrano@gmail.com
>>Sent: Tue, 24 May 2005 12:39:04 +0200
>>To: pgsql-bugs@postgresql.org, pgsql-sql@postgresql.org
>>Subject: Re: [SQL] could not devise a query plan
>>
>>Dear Gurus,
>>
>>Sorry for upping a 13-month-old thread; please tell if I should've opened
>>another one.
>>
>>Here I come again, with another silly join. Please forgive me, but our
>>queries are built from blocks :)
>>
>>VERSION: 7.4.6, 7.4.8, 8.0.0rc4 (sorry, no newer installed right now)
>>
>>ABSTRACT: The following query fails.
>>
>>	SELECT * FROM
>>	  (SELECT a,b FROM cdqp WHERE a=1 AND b=2) AS aa
>>	  NATURAL FULL JOIN
>>	  (SELECT a,b FROM cdqp WHERE a=1 and b=2) AS bb
>>	WHERE a+b = 3;
>>
>>DETAILS: It seems it's something about the redundant WHERE clauses. If I
>>comment (replace with "WHERE true") any of the three WHERE clauses, it
>>works.
>>
>>Session log: See below.
>>
>>TIA,
>>
>>--
>>G.
>>
>>
>>serv1:tir=> \d cdqp
>>    Table "pg_temp_20.cdqp"
>>  Column |  Type   | Modifiers
>>--------+---------+-----------
>>  a      | integer |
>>  b      | integer |
>>
>>serv1:tir=> SELECT * FROM
>>serv1:tir->   (SELECT a,b FROM cdqp WHERE a=1 AND b=2) AS aa
>>serv1:tir->   NATURAL FULL JOIN
>>serv1:tir->   (SELECT a,b FROM cdqp WHERE a=1 and b=2) AS bb
>>serv1:tir-> WHERE a+b = 3;
>>ERROR:  could not devise a query plan for the given query
>>serv1:tir=> SELECT * FROM
>>serv1:tir->   (SELECT a,b FROM cdqp WHERE a=1 AND b=2) AS aa
>>serv1:tir->   NATURAL FULL JOIN
>>serv1:tir->   (SELECT a,b FROM cdqp WHERE a=1 and b=2) AS bb
>>serv1:tir-> WHERE true;
>>  a | b
>>---+---
>>  1 | 2
>>(1 row)
>>
>>---------------------------(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