Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Tom> * I'm almost thinking that changing to list_union is a bad idea,
> A fair point. Though it looks like list_union is used in only about 3
> distinct places, and two of those are list_union(NIL, blah) to simply
> remove dups from a single list. The third place is the cartesian-product
> expansion of grouping sets, which uses list_union_int to remove
> duplicates - changing the order there will give slightly user-surprising
> but not actually incorrect results.
> Presumably list_concat_unique should be considered to guarantee that it
> preserves the relative order of the two lists and of the non-duplicate
> items in the second list?
I'm thinking that whichever coding we use, the patch should include
comment additions in list.c documenting that some callers have assumptions
thus-and-so about list order preservation. Then at least anybody who
got the idea to try to improve performance of those functions would be on
notice about the risks.
I see that list_union is currently documented like this:
* Generate the union of two lists. This is calculated by copying
* list1 via list_copy(), then adding to it all the members of list2
* that aren't already in list1.
so as long as it stays like that, it's not unreasonable to use it in
this patch. I just want the potential landmine to be obvious at that
end.
regards, tom lane
