Feedback-ID: ia2694551:Fastmail
Date: Wed, 19 Feb 2025 22:09:16 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Mahendra Singh Thalor <mahi6run@gmail.com>
Cc: jian he <jian.universality@gmail.com>, 
	Srinath Reddy <srinath2133@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: Non-text mode for pg_dumpall
Message-ID: <202502192109.5ifhfegolh6w@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKYtNAoyQV-UKosfFDfm_ZqdC-oYaRT-01jMv1k+o9OSyXovTg@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202502192109.5ifhfegolh6w%40alvherre.pgsql>
Precedence: bulk

Hello,

I think the business with an evergrowing on_exit list needs a different
solution than a gigantic array of entries.  Maybe it would make sense to
restructure that code so that there's a single on_exit item, but there
exists a list of per-database entries to clean up which are all done in
one call of the function.  Then you don't need to change the hardcoded
MAX_ON_EXIT_NICELY array size there.

I think it would be better to have a preparatory 0001 patch that just
moves the code to the new files, without touching anything else, and
then the new feature is introduced as a separate 0002 commit.

You still have a bunch of XXX items here and there which look to me like
they need to be handled before this patch can be considered final, plus
the TODOs in the commit message.  Please pgindent.

Thanks

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?"  (Mafalda)