"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> such a hokey query (how many applications really write "WHERE false"?),
>
>> Granted this isn't WHERE FALSE, but I certainly see WHERE TRUE all the
>> time in similar scenarios and I have
Thank you for the fix.
--
Miroslav
Tom Lane napsal(a):
> I wrote:
>
>> Bottom line seems to be that we should run through the in_info_list and
>> force Vars mentioned therein to be propagated up at least to the
>> "righthand" join level, ensuring they're available if we decide to
>> unique-ify
I wrote:
> Bottom line seems to be that we should run through the in_info_list and
> force Vars mentioned therein to be propagated up at least to the
> "righthand" join level, ensuring they're available if we decide to
> unique-ify above that point.
I've committed a patch along these lines --- if
Just an explanation why I create such a weird WHERE clause. I have a
form definition that should on initialization load no records in list,
that's the reason why 'false' is there. But every query goes through
layer that adds extra clause to the original one to allow access only to
records the user
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> such a hokey query (how many applications really write "WHERE false"?),
> Granted this isn't WHERE FALSE, but I certainly see WHERE TRUE all the
> time in similar scenarios and I have seen WHERE FALSE.
In what context? Either "W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> =?ISO-8859-2?Q?Miroslav_=A9ulc?= <[EMAIL PROTECTED]> writes:
>> Here is the complete dump and the query. In my case the bug is
>> reproducible using it.
> In a perfect world we'd not have this problem because
> const-simplification w
=?ISO-8859-2?Q?Miroslav_=A9ulc?= <[EMAIL PROTECTED]> writes:
> Here is the complete dump and the query. In my case the bug is
> reproducible using it.
> # SELECT Invoice.* FROM Invoice WHERE false AND InvoiceGroupId IN (SELECT
> InvoiceGroup.Id FROM InvoiceGroup INNER JOIN PartnerBranch ON
> Invoi
Tom Lane napsal(a):
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
>> Miroslav Ĺ ulc wrote:
>>
>>> I just verified that the problem is in pg 8.2.5 too.
>>>
>
>
>> Can you show us the table definitions?
>>
>
> We need a *complete* test case, ie, a SQL script to provoke the err
Tom Lane napsal(a):
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
>> Miroslav Ĺ ulc wrote:
>>
>>> I just verified that the problem is in pg 8.2.5 too.
>>>
>
>
>> Can you show us the table definitions?
>>
>
> We need a *complete* test case, ie, a SQL script to provoke the err
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Miroslav Å ulc wrote:
>> I just verified that the problem is in pg 8.2.5 too.
> Can you show us the table definitions?
We need a *complete* test case, ie, a SQL script to provoke the error
starting from an empty database.
regar
Here they are:
CREATE TABLE invoice
(
id int4 NOT NULL,
description text NOT NULL,
textcontent text NOT NULL,
itemnumber int4 NOT NULL,
fiscalyear int2 NOT NULL,
identification varchar(25) NOT NULL,
partneridentificationid int4,
executoruserid int2 NOT NULL,
partnerid int4,
va
Miroslav Šulc wrote:
> I just verified that the problem is in pg 8.2.5 too.
Can you show us the table definitions?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end
I just verified that the problem is in pg 8.2.5 too.
--
Miroslav Šulc
Miroslav Šulc napsal(a):
> Just copied client database from production server to my dev database
> and ran the query on my dev database and it fails too so it seems it
> also depends on whether some data are contained in the ta
Just copied client database from production server to my dev database
and ran the query on my dev database and it fails too so it seems it
also depends on whether some data are contained in the tables or not.
--
Miroslav Šulc
Miroslav Šulc napsal(a):
> Hi,
>
> I get this error when running this
Hi,
I get this error when running this query (generated by code so it is not
ideal though still valid I guess):
SELECT Invoice.* FROM Invoice WHERE false AND InvoiceGroupId IN (SELECT
InvoiceGroup.Id FROM InvoiceGroup INNER JOIN PartnerBranch ON
InvoiceGroup.PartnerBranchId = PartnerBranch.Id WH
Angva <[EMAIL PROTECTED]> writes:
> In running a query I receive the error:
> ERROR: variable not found in subplan target lists
Please provide a complete test case.
regards, tom lane
---(end of broadcast)---
TIP 6: explain
In running a query I receive the error:
ERROR: variable not found in subplan target lists
The version is 8.1.5
I can find references to this message. Seems there was a bug in older
versions. Should I be finding this in 8.1.5? Any advice?
Thank you and much appreciated.
Mark
17 matches
Mail list logo
