Re: not fully correct error message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: not fully correct error message
Date: 2026-01-03 18:03:42
Message-ID: 409108.1767463422@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andreas Karlsson <andreas(at)proxel(dot)se> writes:
> On 1/3/26 1:22 PM, Marcos Pegoraro wrote:
>> Em sáb., 3 de jan. de 2026 às 03:35, Pavel Stehule
>> <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>> escreveu:
>>> here is a patch (with small regress test)

>> An anonymous block doesn't accept vacuum too.
>> Wouldn't it be better to specify what kind of block you are running
>> instead of function, procedure or anonymous block ?

I don't think PreventInTransactionBlock has ready access to that
information.

> A potential third option would be to take your solution but to add a
> HINT about that it needs to run as a top-level statement outside any
> transactions, but I kinda liked how simple the original patch was.

Yeah, I like just adding "or procedure" and calling it good.
I do not think we need a regression test, either ...

Poking around, I also found this:

src/backend/commands/wait.c: errdetail("WAIT FOR cannot be executed from a function or a procedure or within a transaction with an isolation level higher than READ COMMITTED."));

which is also not great grammar. What do you think of "WAIT FOR
cannot be executed from a function or procedure, nor within a
transaction with an isolation level higher than READ COMMITTED." ?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahendra Singh Thalor 2026-01-03 18:29:20 Re: Non-text mode for pg_dumpall
Previous Message Tom Lane 2026-01-03 17:42:55 Re: more POSIX 2008 cleanup: strnlen(), rindex()