From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: full outer join bug? |
Date: | 2001-11-18 19:20:23 |
Message-ID: | 3507.1006111223@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> SELECT * FROM t1 FULL JOIN t2 USING (name) FULL JOIN t3 USING (name);
> ERROR: FULL JOIN is only supported with mergejoinable join conditions
I think we're kinda stuck with that in the near term. A possible
workaround is
SELECT * FROM t1 FULL JOIN t2 on t1.name=t2.name
FULL JOIN t3 on t1.name=t3.name;
or similarly
SELECT * FROM t1 FULL JOIN t2 on t1.name=t2.name
FULL JOIN t3 on t2.name=t3.name;
each of which is slightly different from the semantics of the original
query, but might be close enough for your purposes.
The problem is that "name" coming out of the t1/t2 full join is not a
simple variable: it's actually a "COALESCE(t1.name,t2.name)" construct.
And the mergejoin code doesn't support mergejoining on anything but
simple variables. And our other join methods don't support FULL JOIN.
So there's no way to build a working plan.
I have plans to revise the handling of join variables at some point
in the future, probably as part of the fabled querytree redesign.
And mergejoining on expressions should be allowed too, sooner or later.
Neither one is going to happen for 7.2 though ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2001-11-18 19:40:59 | Re: OCTET_LENGTH is wrong |
Previous Message | Bruce Momjian | 2001-11-18 19:17:07 | Re: OCTET_LENGTH is wrong |