Implement IF NOT EXISTS for CREATE PUBLICATION AND CREATE SUBSCRIPTION
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:t47592psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:52 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 t47592_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 t47592_1 && git checkout t47592_1Patchset v1 (message #1) is on t47592_1
Hi,
Currently we don't support "IF NOT EXISTS" for Create publication and
Create subscription, I felt it would be useful to add this "IF NOT
EXISTS" which will create publication/subscription only if the object
does not exist.
Attached patch for handling the same.
Thoughts?
Regards,
Vignesh
vignesh C <vignesh21@gmail.com> writes:
Currently we don't support "IF NOT EXISTS" for Create publication and
Create subscription, I felt it would be useful to add this "IF NOT
EXISTS" which will create publication/subscription only if the object
does not exist.
Attached patch for handling the same.
Thoughts?
I generally dislike IF NOT EXISTS options, because they are so
semantically squishy: when the command is over, you cannot make any
assumptions whatsoever about the properties of the object, beyond
the bare fact that it exists. I do not think we should implement
such options without a pretty compelling argument that there is a
use-case for them. "I felt it would be useful" doesn't meet the
bar IMO.
CREATE OR REPLACE doesn't have this semantic problem, but I'm not
sure whether it's a useful approach for these types of objects.
regards, tom lane