It seems to me a reasonable way to implement VARIANT would be to have
a data type called VARIANT that stores an OID of the inner type at the
beginning, followed by the binary data. When you say
pg_typeof(somevariant), you'll get 'variant'. Instead, you'd use a
function like this:
variant_typeof(VARIANT) returns REGTYPE
VARIANT could then be casted to/from other types. I think the rules
for converting to/from variant should be a little stronger than normal
PostgreSQL casting rules. For example:
SELECT '12345'::TEXT::INT; -- allowed
SELECT '12345'::TEXT::VARIANT::INT; -- not allowed
SELECT '12345'::TEXT::VARIANT::TEXT::INT; -- allowed
I'm not sure how conversions to/from VARIANT could be implemented
other than creating conversion functions for every type. It'd be nice
if we could avoid that.
A more permissive way to convert out of VARIANT might be to have a
function like this:
variant_unwrap(VARIANT) returns TEXT -- user casts to desired type
I suppose the in/out functions could prefix the value with the type
name and a colon:
> SELECT '12345'::INT::VARIANT;
variant
-------------
integer:12345
The VARIANT type, or similar, would be useful for the JSON data type
I've been intermittently working on, as it would allow us to create a
function like this:
from_json(JSON) returns VARIANT
from_json would unwrap a JSON string/number/bool/null/array,
converting it to a VARIANT whose inner type is TEXT / (INT or BIGINT
or DOUBLE or NUMERIC) / BOOL / [null] / ARRAY. In the [null] case,
from_json would actually return NULL (I see no need for VARIANT to
wrap nulls).
This is rather type-safe compared to what I currently have:
from_json(JSON) returns TEXT -- user casts to desired type
By returning variant, we can then cast to the desired type, and if the
cast is invalid, a type error will occur.
Joey Adams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
