Re: Parallel safety of CURRENT_* family

I wrote:
> Yeah, I didn't have any doubt that it was real.  Still don't know
> why my test case isn't doing what I expected, though.

Doh: the planner knows that transaction_timestamp() is stable, so
it concludes that the DISTINCT condition is vacuous.  There is a
"Unique" node in the plan, but it has zero columns to compare, so
it thinks the tuple are all equivalent and emits only the first.

I had noticed that there was no "Sort" node, but failed to realize
that that implied the "Unique" node was degenerate.

Maybe this is over-optimization, but I think we'd be very sad if
the planner didn't do it; getting rid of useless sort columns is
critical in a lot of situations.
        regards, tom lane