On 4/7/15 4:17 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> I've created a variant data type [1]. It seems to work pretty well,
>> except for some issues with casting.
>
>> Since the idea of the type is to allow storing any other data type, it
>> creates casts to and from all other types. At first these were all
>> marked as ASSIGNMENT, but that made using variant with functions quite
>> cumbersome. With functions that accepted a variant, you still had to
>> explicitly cast it:
>
>> SELECT variant_function( some_field::variant.variant ) FROM some_table;
>
>> I was reluctant to make the casts to variant IMPLICIT, but it seems like
>> it actually works rather well... except for arrays:
>
> I suspect that that's only the tip of the iceberg. Remember the mess
> we had with implicit casts to text? And those only existed for a dozen
> or so types, not for everything. Every function or operator you define
> for "variant" is going to be a loaded gun just waiting to shoot your foot
> off, if you make all those casts implicit.
Yeah, that's why I avoided it. But that makes using it in a function a
real pain. :( I think this is a bit of a different scenario though,
because I don't see why you'd want to overload a function to accept both
variant and some other type.
Really what I want is for casting to variant to be a last-choice option,
and even then only for function calls, not operators. I believe that
would be safe, because then you'd have to explicitly be calling a
function, or explicitly doing something::variant = variant.
The other option I thought of was controlling this better by putting the
variant operators in their own schema, but that didn't work.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com