Re: CAST Within EXCLUSION constraint

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Wed, Aug 21, 2013 at 10:13:15AM -0400, Tom Lane wrote:
>> The reason for that is you'd get randomly different results on another
>> installation. In this particular application, I think David doesn't
>> really care about what values he gets as long as they're distinct,
>> so this might be an OK workaround for him. But that's the reasoning
>> for the general prohibition.

> While a WITHOUT FUNCTION cast does *guarantee* that flaw, working around the
> restriction with a cast function is all too likely to create the same flaw.
> Here's the comment about the restriction:

> * Theoretically you could build a user-defined base type that is
> * binary-compatible with a composite, enum, or array type. But we
> * disallow that too, as in practice such a cast is surely a mistake.
> * You can always work around that by writing a cast function.

> That's reasonable enough, but we could reduce this to a WARNING. Alexander
> shows a credible use case. A superuser can easily introduce breakage through
> careless addition of WITHOUT FUNCTION casts. Permitting borderline cases
> seems more consistent with the level of user care already expected in this
> vicinity.

Well, if we're gonna allow it, let's just allow it --- I don't see much
point in a WARNING here. As you say, superusers are presumed to be
responsible adults.

regards, tom lane