Re: BUG #15352: postgresql FDW error "ERROR: ORDER BY position 0 is not in select list"
От | Andrew Gierth |
---|---|
Тема | Re: BUG #15352: postgresql FDW error "ERROR: ORDER BY position 0 is not in select list" |
Дата | |
Msg-id | 87a7paz8b1.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: BUG #15352: postgresql FDW error "ERROR: ORDER BY position 0 is not in select list" (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15352: postgresql FDW error "ERROR: ORDER BY position 0 is not in select list"
|
Список | pgsql-bugs |
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes: Andrew> So what's happening here is that there's an equivalence class Andrew> containing members Andrew> "greatest(pg_catalog.pg_stat_user_tables.idx_scan, Andrew> public.pg_stat_user_tables.idx_scan)" and "0" (as an integer Andrew> constant), and somehow a pathkey for this eclass is becoming Andrew> attached to the query going to the remote for statistics Andrew> purposes. Andrew> It seems obviously wrong that a constant pathkey with no actual Andrew> reference to the foreign table should be being pushed down, so Andrew> so far I suspect that get_useful_pathkeys_for_relation isn't Andrew> being selective enough about what is "useful". In this context Andrew> I find it suspicious that find_em_expr_for_rel will return an Andrew> expr with no vars as being "for" every rel, since it's just Andrew> looking for a subset. So this looks to me like an oversight in aa09cd242 (CCing rhaas and Ashutosh accordingly), which changed find_em_expr_for_rel from using bms_equal to bms_is_subset without considering the degenerate case of members with no relids at all. I propose to simply add a !bms_is_empty condition there; anyone have any better idea? -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: