From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: VARIANT / ANYTYPE datatype |
Date: | 2011-05-11 13:12:27 |
Message-ID: | 4DCA8B3B.3090709@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/11/2011 07:53 AM, Robert Haas wrote:
> On Tue, May 10, 2011 at 10:29 PM, Joseph Adams
> <joeyadams3(dot)14159(at)gmail(dot)com> wrote:
>> 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.
> That's likely to be how it gets implemented, but you seem to have
> missed the point of some of the discussion upthread: the big problem
> with that is that someone might type "DROP TYPE foo", and when they
> do, you need an efficient way to figure out whether foo is in use
> inside an instance of the variant type anywhere in the system. The
> devil is in the details...
>
Actually, I thought that was the variant (pun intended) Tom objected to,
and wanted declared variant types instead, precisely so we could know
where we'd need to look if a type was dropped. Using that you might
still use the type oid at the beginning of the field, but there are
other possibilities too (e.g. a single byte indicating which known
variant is in use).
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | nil nil | 2011-05-11 13:46:37 | Help required regarding patch development |
Previous Message | Pavan Deolasee | 2011-05-11 12:46:31 | Re: crash-safe visibility map, take five |