Print baserestrictinfo for varchar fields
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:t40692psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 12:41 PM.
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 t40692_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 t40692_1 && git checkout t40692_1Patchset v1 (message #1) is on t40692_1
Hi,
I noticed that debug_print_rel outputs "unknown expr" when the fields
in baserestrictinfo are typed as varchar.
create table tbl_a(id int, info varchar(32));
RELOPTINFO (tbl_a): rows=4 width=86
baserestrictinfo: unknown expr = pattern
My approach is to handle the RelabelType case in print_expr. After
the patch, I get:
RELOPTINFO (tbl_a): rows=4 width=86
baserestrictinfo: tbl_a.info = pattern
I wonder if this is a proper way of fixing it?
Thank you,
Donald Dong
Donald Dong <xdong@csumb.edu> writes:
I noticed that debug_print_rel outputs "unknown expr" when the fields
in baserestrictinfo are typed as varchar.
...
I wonder if this is a proper way of fixing it?
It's hard to muster much enthusiasm for extending print_expr(),
considering how incomplete and little-used it is. I'd rather
spend effort on ripping it out in favor of using the far more
complete, and better-tested, code in ruleutils.c.
regards, tom lane
On Mon, Jun 03, 2019 at 01:37:22AM -0400, Tom Lane wrote:
It's hard to muster much enthusiasm for extending print_expr(),
considering how incomplete and little-used it is. I'd rather
spend effort on ripping it out in favor of using the far more
complete, and better-tested, code in ruleutils.c.
If it is possible to get the same amount of coverage when debugging
the planner, count me in. Now it seems to me that we'd still require
some work to get the same level of information as for range table
entry kinds..
--
Michael