On 4/7/15 4:17 PM, Tom Lane wrote:
Jim Nasby <jim.na...@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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
