| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: Let's drop two obsolete features which are bear-traps for novices |
| Date: | 2014-11-02 22:42:53 |
| Message-ID: | 5456B36D.9010900@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/02/2014 02:41 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 11/02/2014 11:53 AM, Tom Lane wrote:
>>> Well, the OID compatibility issue could be dodged by saying that we can't
>>> do a pg_upgrade (in-place upgrade) of a database containing MONEY
>>> columns. In fact, we might be able to just reject databases containing
>>> MONEY[] (array) columns, which seems like it might be only a minor hazard.
>>> Either way, requiring a dump/reload for upgrade is surely a better answer
>>> for users of the type than just summarily screwing them.
>> Well, OK, yes, if we're prepared to abandon pg_upgrade-ability.
> Not following your point? Removing the type entirely would certainly
> break pg_upgrade-ability as well.
>
>
I'm not entirely convinced that we should remove it.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Harrington | 2014-11-02 23:05:09 | Re: [JDBC] Pipelining executions to postgresql server |
| Previous Message | Marko Tiikkaja | 2014-11-02 21:53:27 | Re: Silly coding in pgcrypto |