From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VARIANT / ANYTYPE datatype |
Date: | 2011-05-06 20:08:38 |
Message-ID: | 1304711381-sup-8566@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-06 20:11:35 | Re: pg_upgrade's bindir options could be optional |
Previous Message | Andrew Dunstan | 2011-05-06 20:08:22 | Re: Why not install pgstattuple by default? |