> On 31 Aug 2022, at 00:20, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <dan...@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/
