Robert Haas <robertmhaas@gmail.com> writes:
> Well, I guess my thought was that we what we were doing is extending
> the coercion system to be able to make decisions based on both type
> OID and typemod.
Well, that's an interesting thought, but the proposal at hand is far
more limited than that --- it's only an optimization that can be applied
in limited situations. If we want to do something like what you're
suggesting here, it's not going to get done for 9.1.
> A further problem is that I don't think it'd play well at all with the
> richer-typemod concept we keep bandying about. If, for example, we
> represented all arrays with the same OID (getting rid of the
> double-entries in pg_type) and used some kind of augmented-typemod to
> store the number of dimensions and the base type, this would
> completely fall over.
Your proposal would completely fall over, you mean. An Expr->Expr hook
API wouldn't be affected at all.
I'm not sure how important that concern is though, because it's hard to
see how any such change wouldn't break existing cast implementation
functions anyway. If the API for length-coercing cast functions
changes, breaking their helper functions too hardly seems like an issue.
Or are you saying you want to punt this whole proposal till after that
happens? I had muttered something of the sort way upthread, but I
didn't think anyone else thought that way.
regards, tom lane
