| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: jsonb and nested hstore |
| Date: | 2014-03-05 15:39:56 |
| Message-ID: | 5317454C.4020601@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03/05/2014 10:30 AM, Tom Lane wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Also, there might be other cases besides arrays where we've embedded
>>> type OIDs in on-disk data; anyone remember?
>> composite types.
> But that's only the composite type's own OID, no? So it's not really
> a problem unless the type we wanted to move into (or out of) core was
> itself composite.
>
>
Sure, although that's not entirely impossible to imagine. I admit it
seems less likely, and I could accept it as a restriction if we
conquered the general case.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-03-05 15:52:08 | Re: jsonb and nested hstore |
| Previous Message | Tom Lane | 2014-03-05 15:30:22 | Re: jsonb and nested hstore |