Re: VARIANT / ANYTYPE datatype - Mailing list pgsql-hackers

From Tom Lane
Subject Re: VARIANT / ANYTYPE datatype
Date
Msg-id 2586.1304715595@sss.pgh.pa.us
Whole thread Raw
In response to Re: VARIANT / ANYTYPE datatype  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Darren Duncan's message of mié may 04 15:33:33 -0300 2011:
>> I see VARIANT/ANYTYPE as the most general case of supporting union types, which, 
>> say, could have more specific examples of "allow any number or date here but 
>> nothing else".  If VARIANT is supported, unions in general ought to be also.

> Okay, so aside from the performance (storage reduction) gained, there's
> this argument for having variant/union types.  It seems to me that this
> is indeed possible to build.  Completely general VARIANT, though, is
> rather complex.

Yeah.  I have no particular objection to a UNION over a specified set of
types, but am not very happy with the idea of an unconstrained union.

Also, a UNION declaration would allow attaching a field name to each
containable type, as I see Andrew just posted about.  That seems like
potentially a good idea.

> In a general variant, the system catalogs do not have the information of
> what type each variant masquerades as.  We would need to examine the
> variant's masqueraded types on each insert; if the current type is not
> found, add it.  This seems a bit expensive.

Not to mention race-condition-prone.  How do you ensure someone is not
inserting another instance of the variant, with some previously not used
content type, while this is going on?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: VARIANT / ANYTYPE datatype
Next
From: Merlin Moncure
Date:
Subject: Re: VARIANT / ANYTYPE datatype