| 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
| 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 |