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