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
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
Teodor Sigaev writes:
> SELECT
> t1, t2
> FROM (
> SELECT t1, t2 FROM wow
> UNION ALL
> SELECT 'a', 'a' FROM wow
> ) t
> ORDER BY t1, t2;
Hmm, interesting.
> It's seems to me that check in create_merge_append_plan() is too restrictive:
> if (memcmp(sortColIdx, node->
Hi!
I ran into a problem with PG 9.1 and bug is observed even in master. After
simplifying a query (original was 9Kb long!) it's possible to reproduce it easily:
CREATE TABLE wow (t1 text, t2 text);
CREATE INDEX idx ON wow (t1,t2);
SET enable_seqscan=off;
SET enable_bitmapscan=off;
EXPLAIN
S
