Re: Let's drop two obsolete features which are bear-traps for novices
От | Andrew Dunstan |
---|---|
Тема | Re: Let's drop two obsolete features which are bear-traps for novices |
Дата | |
Msg-id | 545684E9.5080209@dunslane.net обсуждение исходный текст |
Ответ на | Re: Let's drop two obsolete features which are bear-traps for novices (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Let's drop two obsolete features which are bear-traps for novices
|
Список | pgsql-hackers |
On 11/02/2014 11:53 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 11/02/2014 10:01 AM, Jaime Casanova wrote: >>> Not knowing how difficult it could be maybe a fair compromise is to >>> move MONEY datatype to a contrib. And documenting its limitations. >> That's pretty much dead in the water, I think. Builtin types and >> functions have Oid values in different ranges from non-builtin types >> such as those in contrib. It's one reason we have no chance of bringing >> hstore into core as people have previously asked for. And for the same >> reason I think moving a core type out to contrib won't work. > 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. > >> In any >> case, contrib shouldn't be a rubbish heap of old deprecated features. > There's a fair amount of contrib that was never anything else, so I don't > agree with that reasoning too much. > > Maybe my memory is failing. What in contrib is stuff that used to be in core? cheers andrew
В списке pgsql-hackers по дате отправления: