> > 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.
>
> It seems to be relatively easy to teach vacuumlo to handle domains over
> oid. Note that you need a recursive query because you can have domains
> over domains. Please test it out.
I think there is value in expanding the vacuumlo search capability for
LOs and OIDs.
We can also detect LOs and OIDs stored in composite types, or OID[] and LO[].
All these are detectable from the catalog.
The one complexity will be we will need vacuumlo to generate more complex
expressions for deleting the data.
DELETE FROM t WHERE lo IN (SELECT ("data")."lo_ref" FROM t_lo);
But, this will be more comprehensive and can cover all potential ways
an OID or LO can be used.
What do you think?
> Please test it out. I noticed that vacuumlo's tests are
> pretty sad, so this might be a good opportunity to change that.
More tests will be needed for sure.
But with all this done, I am not sure how much this moves the needle. It may
somewhat, but it's hard to tell how much.
I know I have seen users store LO references in text or other types,
so I think we still need the documentation enhancement to call out
the "data loss" potential.
I also think it will be good for the LO documentation [1] to nudge the users
to think about using the LO extension, as is done with the vacuumlo [2]
documentation.
[1] https://www.postgresql.org/docs/current/lo.html
[2] https://www.postgresql.org/docs/current/vacuumlo.html
--
Sami
