Re: Add custom EXPLAIN options support to auto_explain

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Lukas Fittl <lukas(at)fittl(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Add custom EXPLAIN options support to auto_explain
Date: 2026-04-06 19:30:49
Message-ID: CA+TgmoaGDHbys0UUzn8hPe9XQJK+HhjsWtqAxpvYJCs6MS1_6g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 3, 2026 at 10:09 PM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
> Per src/backend/utils/misc/README, "extra is initialized to NULL
> before call, so it can be ignored if not needed." - so we don't have
> to set extra here.

Fair enough, but it's not an uncommon practice. See, e.g.
check_synchronous_standby_names(), check_backtrace_functions().

> You note in a separate comment that we're using a subset of the main
> parser, but maybe its worth calling out integer values in particular,
> since things like "100_000" are not supported (since we're not using
> pg_strtoint64_safe + deal with the complexity of that in the scanning
> logic). I think this could be a code comment for now.

OK, done.

> I think this function probably has the most complexity due to its
> hand-rolled parsing, so it might be good if someone else takes another
> close look at it.

Agreed, but I've committed this for now. If someone finds a problem
later, it can be revised or reverted.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jimmy Angelakos 2026-04-06 19:33:19 Re: [PATCH] pg_dump: Restore extension config table data before user objects during pg_upgrade
Previous Message Matheus Alcantara 2026-04-06 19:27:37 Re: Add custom EXPLAIN options support to auto_explain