Andres Freund <andres@2ndquadrant.com> writes:
> But I guess given the objections on performance the combined approach is
> the way to go?
I think the documentation approach is the way to go.
It was pointed out in the pgsql-general thread about this that a naive
user might expect that, say, syntax or datatype violations in a CASE arm
would not get raised if the CASE doesn't select that arm. We, who know
that all such errors are thrown in the parser, might say that's silly
--- but why? I think it's not that far from acknowledging that some
errors will be thrown pre-execution to acknowledging that errors
produced by constant-folding can be thrown pre-execution, even if
they're inside a CASE. Where is the bright line that says we can
complain about 42+'bogus' in that context but not about 1/0?
If there were realistic use-cases for this sort of thing then I'd have
more sympathy for contorting the planner code to support them, but I'm
not seeing that. The examples shown so far are all pretty artificial,
unless your intent is to throw an error when the CASE fails; and in that
case why not do it with a volatile function containing a RAISE? Not
only will the planner handle that as you want, but it lets you report
an actually-useful message.
regards, tom lane