From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ERROR: MergeAppend child's targetlist doesn't match MergeAppend |
Date: | 2011-11-08 23:28:10 |
Message-ID: | 3154.1320794890@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Not immediately sure what to do about this. The quick-and-dirty fix
> would be to only apply add_child_rel_equivalences to simple inheritance
> child relations, for which the added items must be Vars and must be
> different (which is what that code is expecting). Seems like a bit of a
> shame to lobotomize planning for UNION cases, though. Maybe we need a
> more complicated representation of child EquivalenceClass members.
After some thought and experimentation, the best fix seems to be to
eliminate the ambiguity by wrapping subquery outputs in PlaceHolderVars
whenever there is a risk of confusion. The attached crude patch fixes
both test cases. It needs work (more comments and a regression test
case would be good), but barring objection I'll push forward with doing
it this way.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
draft-mergeappend-fix.patch | text/x-patch | 3.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-08 23:39:19 | Re: lexemes in prefix search going through dictionary modifications |
Previous Message | Josh Berkus | 2011-11-08 23:25:14 | Re: Materialized views |