Kevin, On Wednesday, September 18, 2013, Kevin Grittner wrote:
> Stephen Frost <sfr...@snowman.net <javascript:;>> wrote: > > > If it's not actually *changing* (wrt its value), then I'm not at > > all impressed with the notion that it's going to get updated > > anyway. > > But PostgreSQL very specifically (and as far as I can tell > *intentionally*) allows you to *change* a value and have it still > be considered *equal*. I'm curious where you're going with that- of course you can update a value and have the same value (and possibly the same byte representation) stored over the old. > The concept of equal values really means > more like "equivalent" or "close enough" for common purposes. It > very specifically does *not* mean the same value. I'm really curious about your thoughts on unique indexes then. Should two numerics which are the same value but different byte representations be allowed in a unique index? > As just one example, think how much easier the citext type would be > to implement if it folded all values to lower case as they were > input, rather than preserving the data as entered and considering > different capitalizations as "equal". If the type operator says they're equal, then I think we need to consider them as equal. If an update happens with a conditional of: where col1 = 'Abc' When col1 is 'ABC' using citext, should we still issue the update? The notion that in PostgreSQL a value has not changed if the new > value is equal to the old is just flat out wrong. The value *can* be changed to be equal to the existing value but that doesn't make the two values *not equal*. Thanks, Stephen
