Date: Tue, 12 May 2026 22:00:15 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Shawn McCoy <shawn.the.mccoy@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Vacuumlo improvements
Message-ID: <agPpPyLs-61qFw88@nathan>
References: 
 <CALsgZNAM=AYK-9ZLR7Z0YLx6Lyx5aSrjjse3T+FmsJ=jTvfhDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CALsgZNAM=AYK-9ZLR7Z0YLx6Lyx5aSrjjse3T+FmsJ=jTvfhDQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/agPpPyLs-61qFw88%40nathan>
Precedence: bulk

On Tue, May 12, 2026 at 11:34:10AM -0600, Shawn McCoy wrote:
> Ideally, vacuumlo could be improved to:
> - Resolve domain types back to their base types when scanning columns
> (using pg_type.typbasetype), or
> - At least emit a WARNING when it encounters columns with domains over
> oid/lo that it is skipping, so the user is aware.

Commit 64c604898e added the note about domains to the docs.  Unfortunately,
neither that nor the corresponding thread [0] offer any clues as to why
vacuumlo doesn't resolve domains.  The commit history for vacuumlo has been
pretty quiet for a long time, so maybe it's just been overlooked.

> At minimum, I can submit a documentation improvement to make the
> data-loss risk more prominent. The current parenthetical note is easy
> to miss.

Improving the documentation seems reasonable, too.  Another thing we could
explore is allowing users to specify which tables/columns refer to LOs,
perhaps with a user-provided query.  One wrinkle is that dblink allows
specifying multiple databases, and presumably each database will be a
little different.

Separately, do you know whether users are using lo_manage() at all?  And if
not, why?

[0] https://postgr.es/m/BAY164-W265A089BD32F8901A686C9FF430%40phx.gbl

-- 
nathan