Re: CAST Within EXCLUSION constraint
От | Noah Misch |
---|---|
Тема | Re: CAST Within EXCLUSION constraint |
Дата | |
Msg-id | 20130822032409.GA607191@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: CAST Within EXCLUSION constraint (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CAST Within EXCLUSION constraint
|
Список | 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 по дате отправления: