Re: CAST Within EXCLUSION constraint - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CAST Within EXCLUSION constraint
Date
Msg-id 24732.1377152126@sss.pgh.pa.us
Whole thread Raw
In response to Re: CAST Within EXCLUSION constraint  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: lob conversion functionality
Next
From: Pavel Stehule
Date:
Subject: Re: PL/pgSQL, RAISE and error context