| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, 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 16:16:01 |
| Message-ID: | 3576.1394036161@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> It seems only pg_type.oid is an issue for hstore. We can easily modify
> pg_dump --binary-upgrade mode to suppress the creation of the hstore
> extension. That should allow user hstore columns to automatically map
> to the new constant hstore oid. We can also modify pg_upgrade to scan
> all the user tables for any use of hstore arrays and perhaps composite
> types and tell the user they have to drop and upgrade those table
> separately.
Yeah, and that doesn't seem terribly acceptable. Unless you think the
field usage of hstore[] is nil; which maybe it is, I'm not sure what
the usage patterns are like. In general it would not be acceptable
at all to not be able to support migrations of array columns.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-03-05 16:19:30 | Re: jsonb and nested hstore |
| Previous Message | Robert Haas | 2014-03-05 16:11:51 | Re: jsonb and nested hstore |