From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Better localization of errors in plpgsql variable initialization |
Date: | 2021-10-29 18:00:14 |
Message-ID: | 713975.1635530414@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While preparing commit a2a731d6c, I chanced to notice what seemed
like an off-by-one error in the line number reported for an error
occurring while we initialize a plpgsql variable. For instance
regression=# do $$ declare x int := 1/0;
regression$# begin end $$;
ERROR: division by zero
CONTEXT: SQL expression "1/0"
PL/pgSQL function inline_code_block line 2 during statement block local variable initialization
After tracking it down, it's not that. It's that we're pointing
at the BEGIN keyword, because that's what determines the lineno
associated with the PLpgSQL_stmt_block struct.
This seems like it could be quite confusing in a block with many
variables, so here's a proposed patch that improves the reported
line number to match the specific variable.
The only downside that I can see here is the one additional store
per variable to set err_var; but it's pretty hard to believe that
that'd be measurable in context.
Any objections?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
blame-init-errors-on-specific-variable-1.patch | text/x-diff | 14.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2021-10-29 18:00:58 | Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION |
Previous Message | Bossart, Nathan | 2021-10-29 17:47:19 | Re: Skip vacuum log report code in lazy_scan_heap() if possible |