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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Comma-separated predicates in simple CASE expressions (f263)
Date: 2022-08-30 22:20:37
Message-ID: 3763943.1661898037@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-08-30 22:22:43 Re: introduce bufmgr hooks
Previous Message Daniel Gustafsson 2022-08-30 22:12:26 Comma-separated predicates in simple CASE expressions (f263)