On Mon, 10 Aug 2026 at 14:39, solai v <solai.cdac@gmail.com> wrote:
>
> Hi all,
>
>
> On Mon, Aug 10, 2026 at 12:32 PM Matthias van de Meent
> <boekewurm+postgres@gmail.com> wrote:
> >
> > Here's version 3 of the patch, which is no more than a rebase.
> >
> > Kind regards,
> >
> > Matthias van de Meent
> > Databricks (https://www.databricks.com)
> >
> > p.s. The upthread issues with datum_image_*() have been resolved in 0d866282b8.
>
>
> I reviewed and tested the v3 patch. I like the idea of exposing the
> existing datum_image_eq() functionality through a SQL-level function,
> pg_datum_image_equal(anyelement, anyelement). I think this can be
> useful, especially for synchronization/update scenarios where we need
> to check whether two values have the same datum representation and
> potentially avoid unnecessary work. So, +1 from my side for
> introducing this function.
Thanks!
> But I do have a couple of suggestions that may make the patch even stronger:
> 1. Add behavioral regression tests
I've added some compare operations in the regression tests. I did not
add the MATERIALIZED test, because that was more a bug in the
underlying code than an issue this patch specifically.
> 2. Slightly expand the documentation - It may be useful to explicitly
> mention that pg_datum_image_equal() is different from the normal SQL
> equality operator. For example, 1.0::numeric and 1.00::numeric compare
> equal using =, but their datum images are different and the new
> function returns false.
I think the example in the functions table already made this clear. I
think adding further explanation on this function's workings would be
excessive.
> It may also be worth documenting the NULL
> behavior, since two NULL arguments return true.
I've added a NULL-example in the attached patch.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
