Re: join_references: variable not in subplan target lists

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: join_references: variable not in subplan target lists
Date: 2003-06-29 03:29:55
Message-ID: 26700.1056857395@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The cited error message appears when loading the attached file (a cut-down
> version of a local development version of the information schema)

I've been able to reduce the problem to this test case:

drop view x1;

CREATE VIEW x1 AS
SELECT 1
FROM pg_type t, pg_proc p
WHERE
t.oid = p.prorettype AND
p.pronamespace IN
(SELECT n.nspname
FROM pg_namespace n, pg_proc p2
WHERE n.oid = p2.pronamespace);

select * from x1;

While I now need to burrow into the IN-as-join code and find out where
it's dropping the ball, I don't think this need stop you from making
progress on the information schema. The reason the problem is appearing
seems to be the implied cast that's getting introduced in the IN
comparison, because pronamespace (an OID) isn't directly comparable
to nspname (a NAME). (They're both getting coerced to TEXT, which once
again points up my opinion that we are way too loose with implicit
coercions to TEXT, but never mind that right now.) In short, the bug is
being triggered only because you're comparing the wrong pair of columns,
and so you'll need to change the query anyway.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-06-29 03:37:03 Re: lru cache replacement
Previous Message Joe Conway 2003-06-29 03:03:28 Re: Missing array support