I wrote:
> If we were to make the casts to ean13 be IMPLICIT instead of assignment,
> then we could have one set of comparison operators and one opclass for
> ean13, and let the restricted types rely on those implicitly.
I tried this and found out it's got one killer disadvantage: if one
writes something like
SELECT ... WHERE isbn_column = 'isbn-constant';
then the unknown-literal constant would get resolved as type EAN13
not type ISBN, which is not what we want. The existing cases where
we rely on implicit promotion, such as varchar vs text, don't have a
problem here because there's no difference in the input syntax.
It might be possible to adjust the parser so that the unknown literal is
resolved as type ISBN and then promoted to type EAN13, but I'm not going
to mess with that sort of thing just before RC1. There may be some
interactions with the domain-related resolution rule changes that Elein
would like to make, too. Something to think about later.
It'd be worth doing something about this, because as contrib/isn now
stands it increases the number of operators named "=" (also "<=" etc) in
a standard installation by more than 50%. That causes a measurable
performance degradation for parsing simple queries, whether or not they
involve any isn datatypes, because of the cost of resolving the meaning
of any use of "=" :-(. And we'd really need more --- the module still
doesn't provide the complete set of cross-isn-type comparisons, meaning
we can't mark any of them as mergejoinable. Ugh.
regards, tom lane