text_enum: same problem as above, plus not acceptable to assume that it
gets the right enum OID, plus very definitely not acceptable to assume
that OID and typmod are the same size, plus I don't like the
undocumented kluge in getBaseTypeAndTypmod that is pretending to supply
the type OID for some small fraction of possible invocation cases.

I think text_enum is probably toast.

This was the ugliest part of the patch, and I mentioned it explicitly in the original submission because I was uncomfortable about it. The proper solution seemed to be to have another allowed cast function signature that would take the regtype rather than the typmod. That got just a little beyond what I wanted to do in the patch, and ugly as the getBaseTypeAndTypmod hack was, it seemed less intrusive.

Another way to skirt the issue was to simply set the typmod of enum types to have their own OID, but a) I wasn't sure what other things the system might be inferring from the presence of a typmod, and b) you just stated that we can't assume that typmod is big enough to hold an OID anyway.

I'm less concerned about the generic return type in this case, since the parser should know the return type when an explicit cast has been called. <Goes to check> Hmm, ok, maybe not. Looks like it's using the return type of the cast function and throwing away the explicit cast information. That's not very nice, but can probably be fixed in the parser.



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not

Reply via email to