Re: Collatability of type "name"

I wrote:
> We could eliminate those two problems if we made "name" have
> typcollation "C" rather than "default", so that its semantics
> wouldn't change without explicit collation specs.  This feels
> like pretty much of a wart to me, but maybe it's worth doing
> in the name of avoiding compatibility issues.  We could still
> unify name_ops with text_ops, but now "name" would act more like
> a domain with an explicit collation spec.

Here's a variant patch that does it like that.  On reflection this seems
like a safer way to proceed.  It feels like a wart because it violates
the system's original assumption that collatable base types all have
DEFAULT_COLLATION_OID, but as far as I can tell that doesn't have any
really severe consequences.  The main ugliness is that CREATE TYPE can
only set typcollation to 0 or DEFAULT_COLLATION_OID for new base types,
meaning that it's impossible to duplicate the behavior of type "name"
in a user-defined type, which seems like an extensibility failure.
But it's not one that I'm sufficiently excited about to wish to fix.
Another point is that there are places in parse_collate.c that suppose
that "domain's typcollation is different from DEFAULT_COLLATION_OID"
is equivalent to "domain's collation was explicitly specified", which
would not be the case for domains over type name.  But this seems to be
isomorphic to the situation where "name" is a domain with COLLATE "C"
over some anonymous base type, so I don't think that any fundamental
semantic breakage ensues.

Barring objections I'm going to push forward with committing this and
unifying name_ops with text_ops.

			regards, tom lane