Gevik Babakhani <[EMAIL PROTECTED]> writes: > First I would like to know how PG's code looked like without the > domains.
IIRC, as far as the datatype coercion and operator/function resolution code were concerned, the domain patch basically consisted of dropping getBaseType() calls in at a bunch of choke points, so that these routines all treat a domain the same as its base type. I was never real happy about this, mainly because it adds extra syscache lookups that buy you nothing when you're not using domains. What would be nice is to revert all that, and instead have domain creation insert explicit cast entries between a domain and its base type into pg_cast, so that domains don't require any special-case code in this part of the system. The problem with that glib answer is that maintaining anything like the current behavior would seem to require that we abandon the current principle that we consider only one-step cast pathways when trying to match arguments to functions. (For instance, a varchar value can be passed to a text-taking function because varchar->text is an implicit cast according to pg_cast. What of a domain over varchar?) And allowing multi-step casts to be chosen automatically is unbelievably scary --- I think it would basically destroy the system's ability to resolve overloaded functions at all, because you can get from any type to any other if you allow enough cast steps. (The unreasonably large number of implicit casts to text aren't helping any here :-() So the hard part of this doesn't really require any understanding of code at all. What we need is a proposal for an algorithm that loosens the casting rules "just enough" to make explicit pg_cast entries for domains work the way we would like them to, without wholesale breakage of situations that have nothing to do with domains. See http://developer.postgresql.org/pgdocs/postgres/typeconv.html Rereading what I just wrote, it might be as simple as allowing a two-step cast in certain cases, only if the first step is a domain to base type coercion (which we assume would be specially marked in pg_cast). But the devil is in the details ... and anyway there might be a cleaner approach than that. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
