Created on 2020-09-28.18:10:25 by nicoe, last changed 4 days ago by ced.
* Cédric Krier [septembre 28, 2020 18:14]: > > Cédric Krier <email@example.com> 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: firstname.lastname@example.org 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.
|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|
|2020-09-29 10:59:57||reviewbot||set||messages: + msg60461|
|2020-09-28 23:10:55||nicoe||set||messages: + msg60456|
messages: + msg60452
|2020-09-28 18:28:53||reviewbot||set||reviews: 312421002|
keyword: + review
|2020-09-28 18:14:34||pokoli||set||status: unread -> chatting|
|2020-09-28 18:14:26||pokoli||set||nosy: + ced|
|2020-09-28 18:14:13||pokoli||set||status: chatting -> unread|
nosy: + pokoli, - ced
Showing 10 items. Show all history (warning: this could be VERY long)