Comma-separated predicates in simple CASE expressions (f263)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t46514psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 11:19 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t46514_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t46514_1 && git checkout t46514_1Patchset v1 (message #1) is on t46514_1
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/