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

From Noah Misch
Subject Re: CAST Within EXCLUSION constraint
Date
Msg-id 20130822032409.GA607191@tornado.leadboat.com
Whole thread Raw
In response to Re: CAST Within EXCLUSION constraint  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CAST Within EXCLUSION constraint
List pgsql-hackers
On Wed, Aug 21, 2013 at 10:13:15AM -0400, Tom Lane wrote:
> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > It seems reasonable to me to cast enum to oid. However, creating casts
> > without function isn't allowed for enums.
> 
> > test=# create cast (source as oid) without function;
> > ERROR:  enum data types are not binary-compatible
> 
> 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,
orarray type.  But we     * disallow that too, as in practice such a cast is surely a mistake.     * You can always
workaround 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.

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Fix Windows socket error checking for MinGW
Next
From: Amit Kapila
Date:
Subject: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])