Thread: Comma-separated predicates in simple CASE expressions (f263)

I was looking at F263 from the SQL standard, Comma-separated predicates in
simple CASE expression, and thinking if we could support this within the
framework we already have at a minimal added cost.  The attached sketch diff
turns each predicate in the list into a CaseWhen node and uses the location
from parsing for grouping in errorhandling for searched case.

Is this a viable approach or am I missing something obvious?

--
Daniel Gustafsson        https://vmware.com/

Daniel Gustafsson <daniel@yesql.se> writes:
> I was looking at F263 from the SQL standard, Comma-separated predicates in
> simple CASE expression, and thinking if we could support this within the
> framework we already have at a minimal added cost.  The attached sketch diff
> turns each predicate in the list into a CaseWhen node and uses the location
> from parsing for grouping in errorhandling for searched case.

> Is this a viable approach or am I missing something obvious?

I don't particularly like duplicating the THEN clause multiple times.
I think if we're going to do this we should do it right, and that
means a substantially larger patch to propagate the notion of multiple
comparison values all the way down.

I also don't care for the bit in transformCaseExpr where you seem
to be relying on subexpression location fields to make semantic
decisions.  Surely there's a better way.

            regards, tom lane

> On 31 Aug 2022, at 00:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> I was looking at F263 from the SQL standard, Comma-separated predicates in
>> simple CASE expression, and thinking if we could support this within the
>> framework we already have at a minimal added cost.  The attached sketch diff
>> turns each predicate in the list into a CaseWhen node and uses the location
>> from parsing for grouping in errorhandling for searched case.
>
>> Is this a viable approach or am I missing something obvious?

Thanks for looking!

> I don't particularly like duplicating the THEN clause multiple times.
> I think if we're going to do this we should do it right, and that
> means a substantially larger patch to propagate the notion of multiple
> comparison values all the way down.

Fair enough, I think that's doable without splitting the simple and searched
case in the parser which I think would be a good thing to avoid.  I'll take a
stab at it.

> I also don't care for the bit in transformCaseExpr where you seem
> to be relying on subexpression location fields to make semantic
> decisions.  Surely there's a better way.

If we group the predicates such a single node contains the full list then we'll
have all the info we need at that point.

--
Daniel Gustafsson        https://vmware.com/