"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thu, Jun 7, 2018 at 4:37 PM, Melanie Plageman <melanieplageman@gmail.com>
> wrote:
>> I thought this would error out because the subquery's result is considered
>> implicit and, in this case, it seems you now have conflicting implicit
>> collations. However, this does not produce an error. What am I missing?
> Data, apparently...I got the same non-error result before inserting a
> record into test1 then I got the expected error.
> Its the function/operator the fails when faced with invalid input, not the
> planner, so the error requires data to provoke.
IIRC this was an intentional decision, made on the grounds that we
can't tell whether the function/operator actually cares about having
a determinate collation or not, so we have to leave it to execution of
that function/operator to complain or not.
If collation had been part of the system design to start with, we'd
probably have insisted on being able to determine this sooner. But
it wasn't, and when we added it, the ability to throw an error sooner
did not seem worth breaking a lot of third-party code for.
regards, tom lane
