From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Better localization of errors in plpgsql variable initialization |
Date: | 2021-10-29 18:09:21 |
Message-ID: | CAFj8pRAjfxGt8ibUiZLMaVedQGZATXyUi=Wt2CPAgEsiM=X92Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
pá 29. 10. 2021 v 20:00 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> 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.
>
>
+1
Regards
Pavel
Any objections?
>
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-10-29 18:09:53 | Re: ThisTimeLineID is used uninitialized in basebackup.c, too |
Previous Message | Daniel Gustafsson | 2021-10-29 18:00:58 | Re: Extension ownership and misuse of SET ROLE/SET SESSION AUTHORIZATION |