On Fri, 2 Oct 2026 at 01:34, Alberto Piai <[email protected]> wrote: > > I wonder what would be the downsides of exposing this function: the > notion of image equality is already user-visible through pg_catalog.*= > (record_image_eq).
I've thought about it, but I couldn't think of any. Adding pg_datum_image_equal actually means that users won't have to go through expensive record (de)construction for binary equality, which would be a very useful performance improvement. > One risk of course is users assuming that some values are equal, and > then being surprised when more updates happen than expected, in > Matthias' use case of data synchronization tools. What do you mean by "more updates than expected"? > For pg_datum_image_equal(), we could write something along the lines of > > This function is intended for specialized purposes such as data > synchronization tools. It is not generally useful for writing queries, > as it might consider two values as different, even though a comparison > with the equality operator would return true. I don't think this is useful. The distinction is already made sufficiently clear in the added docs, and because the function doesn't map to indexable operators there's little chance people will accidentally use this when they actually want their type's = operator. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
