Re: VARIANT / ANYTYPE datatype

On 05/06/2011 04:08 PM, Alvaro Herrera wrote:
> 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.  A declared union, where you specify exactly which types
> can be part of the union, can be catalogued, so that the system knows
> exactly where to look when a type needs to be modified.  A general
> VARIANT however looks complex to me to solve.
>
> The problem is this: if an user attempts to drop a type, and this type
> is used in a variant somewhere, we would lose the stored data.  So the
> drop needs to be aborted.  Similarly, if we alter a type (easy example:
> a composite type) used in a variant, we need to cascade to modify all
> rows using that composite.
>
> If the unions that use a certain type are catalogued, we at least know
> what tables to scan to cascade.
>
> 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.
>



So how is a declared union going to look and operate? Something like this?
    CREATE TYPE foo AS UNION (ival int, tval text, tsval timestamptz):    CREATE TABLE bar (myunion foo);    INSERT
INTObar (myunion) VALUES (ival=>1), (tval=>'some text');    UPDATE bar SET myunion.tsval = CURRENT_TIMESTAMP;
 


Something like that could actually be quite nice for a number of purposes.


cheers

andrew