Re: SQL-level pg_datum_image_equal

On Fri, 2 Oct 2026 at 01:34, Alberto Piai <alberto(dot)piai(at)gmail(dot)com> 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)