Feedback-ID: ia2694551:Fastmail
Date: Mon, 17 Jul 2023 16:24:52 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	Masahiko Sawada <sawada.mshk@gmail.com>,
	Euler Taveira <euler@eulerto.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: logicalrep_message_type throws an error
Message-ID: <20230717142452.74yml7mfqkypfixp@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAExHW5vvhhtdv-LctC5Wz-yuyh1me3KtvyuOqX48BRQicDGTJg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230717142452.74yml7mfqkypfixp%40alvherre.pgsql>
Precedence: bulk

On 2023-Jul-17, Ashutosh Bapat wrote:

> Prologue of psprintf() says
> 
> * Errors are not returned to the caller, but are reported via elog(ERROR)
> * in the backend, or printf-to-stderr-and-exit() in frontend builds.
> * One should therefore think twice about using this in libpq.
> 
> If an error occurs in psprintf(), it will throw an error which will
> override the original error. I think we should avoid any stuff that
> throws further errors.

Ooh, yeah, this is an excellent point.  I agree it would be better to
avoid psprintf() here and anything that adds more failure modes.  Let's
just do the thing in the original patch you submitted, to ensure all
these strings are compile-time constants; that's likely the most robust.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Pensar que el espectro que vemos es ilusorio no lo despoja de espanto,
sólo le suma el nuevo terror de la locura" (Perelandra, C.S. Lewis)