Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote: >>> I can understand claiming that the risk is acceptable but >>> arguing it's not there seems extremly strange to me. >> >> It's not a risk. It's why the operator exists. > > Pft. It's fine if the materialized view code uses it. I don't see > the danger there. > It's about users discovering it. If they notice it, they will use > it because "its a crapload faster" than normal row comparisons.
To have clean semantics, I think the operator should mean that the stored format of the row is the same. Regarding the array null bitmap example, I think it would be truly weird if the operator said that the stored format was the same, but this happened: test=# select pg_column_size(ARRAY[1,2,3]); pg_column_size ---------------- 36 (1 row) test=# select pg_column_size((ARRAY[1,2,3,NULL])::int4[3]); pg_column_size ---------------- 44 (1 row) They have the same stored format, but a different number of bytes?!? > And deals with NULLs in a "simpler" way. That might be addressed by leaving room to implement IS NOT DISTINCT FROM as an operator. See below. >> Perhaps the name of the operator (===) or the fact that I've >> been using the shorthand description of "identical" instead of >> writing out "record image equals" in these emails has confused >> you. > > If you really think that "confusing you" is the correct > description for concerns about users not understanding > limitations (which you didn't seem to know about), go ahead. Way > to go to solicit feedback. I see how that could be taken in a pejorative way; that was not intended. I apologize. I was rushing a bit on that email to make an appointment shortly afterward. The point was to suggest that bad communication on my part about the intent and concept of the operator may have contributed to you saying that there was a risk of it working as intended. There is perhaps a risk that someone will think that it does something other than what is intended, but when you say that there is a "risk" that it will behave exactly as intended, it does suggest that we're talking past each other. >> I can stop using the shorter description and have absolutely no >> attachment to the operator name, if that helps. > > You're unfortunately going to need operators if you want > mergejoins to work, right? Yes, operators are needed for that. > If not I'd have said name it matview_needs_update() or something > like that... But yes, === certainly seems like a bad idea. I've come to agree with that. The appointment was to meet with a local PostgreSQL user who I've talked to before. He reminded me that his pet peeve was that he couldn't use IS [ NOT ] DISTINCT FROM with the ALL | ANY construct because the IS [ NOT ] DISTINCT FROM predicate isn't an operator. Hannu Krosing <ha...@2ndquadrant.com> wrote: > Maybe the binary equality operator should be named ==== > for "really deeply equal" > > to distinguish it from === which would be merely NOT DISTINCT FROM > > we could even go one step further and define ===== to mean "the same". > > ? > > This could fit better in conceptual sequence of operator 'strength' I'm inclined to go with this. It would leave the door open to implementing IS NOT DISTINCT FROM on a type-by-type basis. My one concern is that it doesn't make room for a "has no user-visible differences from" operator; but I'm not sure whether that is something that there really is any use for. But if we want to reserve name space for it "just in case" someone has a use for it, that would be between IS NOT DISTINCT FROM and "has the same storage representation as", so that would leave: = equals (but doesn't necessarily look the same as) === IS NOT DISTINCT FROM as an operator ==== reserved for "has no user-visible differences from" ===== stored image is the same Of course, that begs the question of whether == is already "taken". If not, we could knock one '=' off of everything above except for "equals". What existing uses are known for == ? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
