Created on 2020-09-28.18:10:25 by nicoe, last changed 3 weeks ago by reviewbot.
* Cédric Krier [septembre 28, 2020 18:14]: > > Cédric Krier <firstname.lastname@example.org> added the comment: > > I think it is too complex to manage the column type. > What about testing by inserting a row with the proper type? Unfortunately it does not work because postgres is doing an implicit CAST when inserting a value into a VARCHAR and it's bypassable only by fiddling with the catalog stuffs. -- Nicolas Évrard - B2CK SPRL E-mail/Jabber: email@example.com Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
I think it is too complex to manage the column type. What about testing by inserting a row with the proper type?
In order to fix issue7962 we introduced a change that drop and recreate the columns month and weekday even if there is no migration to handle. When executing the migration a great number of time we reach the maximum number of column permitted on a postgresql because postgres never removes the dropped column but hides it: https://nerderati.com/2017/01/03/postgresql-tables-can-have-at-most-1600-columns/ I propose to add to the backend table handler a way to retrieve the column type and change the test to check if the column should be dropped or not.
|2021-01-06 14:14:33||reviewbot||set||messages: + msg63792|
|2021-01-05 16:48:48||reviewbot||set||messages: + msg63768|
|2020-12-16 11:47:08||reviewbot||set||messages: + msg63298|
|2020-12-11 16:26:13||reviewbot||set||messages: + msg63036|
|2020-12-01 13:59:35||reviewbot||set||messages: + msg62325|
|2020-12-01 00:29:17||reviewbot||set||messages: + msg62324|
|2020-11-20 14:25:41||reviewbot||set||messages: + msg62058|
|2020-10-22 00:05:04||ced||set||status: chatting -> testing|
|2020-10-19 19:07:25||reviewbot||set||messages: + msg61060|
|2020-10-09 10:51:26||reviewbot||set||messages: + msg60697|
Showing 10 items. Show all history (warning: this could be VERY long)