remove WITHOUT OIDS syntax for v19
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:t51928psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:22 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 t51928_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 t51928_1 && git checkout t51928_1Patchset v1 (message #1) is on t51928_1
Hi hackers,
WITH OIDS was removed in v12, I'm wondering if we could remove the
WITHOUT OIDS support for v19.
attach is the trivial patch for $subject.
--
Regards
Junwang Zhao
Junwang Zhao <zhjwpku@gmail.com> writes:
WITH OIDS was removed in v12, I'm wondering if we could remove the
WITHOUT OIDS support for v19.
Why?
regards, tom lane
On Tue, Jul 15, 2025 at 11:06:11PM +0800, Junwang Zhao wrote:
WITH OIDS was removed in v12, I'm wondering if we could remove the
WITHOUT OIDS support for v19.
AFAICT this would produce less helpful error messages and might even break
applications, which I don't think is worth it to save ~90 lines.
--
nathan
On Tue, Jul 15, 2025 at 11:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Junwang Zhao <zhjwpku@gmail.com> writes:
WITH OIDS was removed in v12, I'm wondering if we could remove the
WITHOUT OIDS support for v19.Why?
Sorry I didn't mention the reason why I think WITHOUT OIDS should be removed.
WITHOUT OIDS has been a backward-compatible syntax for 6 years, so I
think maybe not too many users use it nowadays. Besides, there are
some hints in the code base that `WITHOUT OIDS` and `with (oids =
false)` will be removed someday(see the following diff), so I wonder
which day should it be?
-/* WITHOUT OIDS is legacy only */
OptWith:
WITH reloptions { $$ = $2; }
- | WITHOUT OIDS { $$ = NIL; }
| /*EMPTY*/
- /*
- * This is not a great place for this test,
but there's no other
- * convenient place to filter the option out.
As WITH (oids =
- * false) will be removed someday, this seems
like an acceptable
- * amount of ugly.
- */
regards, tom lane
--
Regards
Junwang Zhao
On Wed, Jul 16, 2025 at 12:49 AM Nathan Bossart
<nathandbossart@gmail.com> wrote:
On Tue, Jul 15, 2025 at 11:06:11PM +0800, Junwang Zhao wrote:
WITH OIDS was removed in v12, I'm wondering if we could remove the
WITHOUT OIDS support for v19.AFAICT this would produce less helpful error messages and might even break
applications, which I don't think is worth it to save ~90 lines.
Yeah, I agree this might break some legacy applications. I don't know
if we have some strategy/policy for removing such legacy syntax, but
do we want to keep this forever?
--
nathan
--
Regards
Junwang Zhao
On Wed, Jul 16, 2025 at 08:06:44AM +0800, Junwang Zhao wrote:
Sorry I didn't mention the reason why I think WITHOUT OIDS should be removed.
WITHOUT OIDS has been a backward-compatible syntax for 6 years, so I
think maybe not too many users use it nowadays. Besides, there are
some hints in the code base that `WITHOUT OIDS` and `with (oids =
false)` will be removed someday(see the following diff), so I wonder
which day should it be?
This is the zone where we would break stuff only for the sake of
breaking it, so it would be annoying for any existing applications
after a major upgrade. Keeping this code is not really a maintenance
burden AFAIK, we can just let it be.
When the WITH OIDS grammar was removed, there were arguments about
code simplifications and ease of support for table access methods,
which had and still have long-term benefits. We still have
default_with_oids in guc_tables.c, for example. That's a nobrainer to
keep it in the GUC tables, and we avoid breaking the world.
--
Michael