Noah Misch <n...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
