* Steve Singer (st...@ssinger.info) wrote: > The problem is that there are datatypes (citext, postgis,...) that > have defined = to return true when comparing two values that are > different not just stored differently.
If the definition of the type is that they're equal, then they're equal.
Certainly there are cases where this is really rather broken
(particularly in the postgis case that you mention), but I don't think
that means we should change our definition of equality to generally be
"are the bytes the same"- clearly that'd lead to incorrect behavior in
the NUMERIC case.
> Are you saying that
> matview's should update only when the = operator of the datatype
> returns false and if people don't like this behaviour they should
> fix the datatypes?
imv, we are depending on the "=" operator to tell us when the
values are equal, regardless of type. I have a hard time seeing how we
can do anything else. The PostGIS situation is already broken when you
consider UNIQUE constraints and, while it's unfortunate that they'd need
to change their data type to fix that, I do feel it's on them to deal
with it.
Anyone can create an extension with their own data type which returns
wrong data and results, it's not on us to figure out how to make those
work even in the face of blatent violations like making "=" not actually
mean "these values are the same".
Thanks,
Stephen
signature.asc
Description: Digital signature
