Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
