You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
The "name" comparison operators now all support collations, making themfunctionally equivalent to "text" comparisons, except for the differentphysical representation of the datatype. They do, in fact, mostly sharethe varstr_cmp and varstr_sortsupport infrastructure, which has beenslightly enlarged to handle the case.To avoid changes in the default behavior of the datatype, set name'stypcollation to C_COLLATION_OID not DEFAULT_COLLATION_OID, so thatby default comparisons to a name value will continue to use strcmpsemantics. (This would have been the case for system catalog columnsanyway, because of commit6b0faf7, but doing this makes it true foruser-created name columns as well. In particular, this avoidslocale-dependent changes in our regression test results.)In consequence, tweak a couple of places that made assumptions aboutcollatable base types always having typcollation DEFAULT_COLLATION_OID.I have not, however, attempted to relax the restriction that user-defined collatable types must have that. Hence, "name" doesn'tbehave quite like a user-defined type; it acts more like a domainwith COLLATE "C". (Conceivably, if we ever get rid of the need forcatalog name columns to be fixed-length, "name" could actually becomesuch a domain over text. But that'd be a pretty massive undertaking,and I'm not volunteering.)Discussion:https://postgr.es/m/15938.1544377821@sss.pgh.pa.us