Isn't there some horrific bug on line 210 of this file?

Are you referring to the assignment in a condition?

Yeah but don't worry I didn't read the code properly. I thought it was supposed to be a check that the two were equal but it's not. Although the else seems unnecessary as we've already set checkStatus to be -1 here https://github.com/sovainfo/joomla-cms/blob/patch-13/libraries/cms/schema/changeitem/postgresql.php#L41 but for another patch

Don't like this construct either. Consider it confusing, don't know whether it is against the coding standard. Not convinced it should be disallowed,Think it deserves documentation.

Did you manage to get this tested?

I did not know how to exactly test this one. So I added one line to the lastest postgresql update file (3.4.0-2014-09-16.sql) in the current branche - ALTER TABLE "#__user_profiles" DROP COLUMN "profile_value"; - and expected not to find this column after the successful installation. But it was present.

If I did do it wrong please advice how to test this.

@waader Thank you for testing. The way to test this is very easy: Run Extension manager->Database on MySQL. It will recognize the ALTER TABLE DROP COLUMN by reporting them when those columns still exist. Running Fix will drop the column. Now test this on PostgreSQL. Find a ALTER TABLE DROP COLUMS in the sql updates. Verifiy whether the column exists, create it if it doesn't. Extension manager->Database should detect it and allow Fix to drop it.

The test you did was testing whether updates can drop columns. No need for testing that, it normally works. Don't know what went wrong with your test, but it is not what this is about. This is about detecting you wanted to drop a column, but it is still there.
Without my PR it doesn't even get noticed!

I installed the current staging branch and went to the Extension manager -> Database and got some messages. Please have a look at #4922.

Then I added a line to 3.3.4-2014-08-03.sql with the ALTER TABLE DROP command and did a refresh. But I got no additional message.

I tried the same with mysql but I got no message just as well. Can you try it yourself and tell me what you did exactly. Thank you!

On 337-dev with this patch applied.
Added: ALTER TABLE "#__user_profiles" drop COLUMN "profile_value" ; to sql script
See last line added because of drop column:

I added ALTER TABLE "#__user_profiles" DROP COLUMN "profile_value"; into https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_admin/sql/updates/postgresql/3.3.6-2014-09-30.sql

Upon applying the patch I found the code ran in the elseif however no extra messages appeared in the database problems view.

Correction. I'm a complete moron and added it into the 3.3.6 mysql file instead of postgres file. works as expected. One more tester

Well, I added the sql statement from @wilsonge in the stated file but I didn´t get the expected result. As I wrote before: neither in my mysql installation nor in my postgres installation an additional line indicates that a column should no be present in a table.

It must have to do with my testing environment - centos 6.5, php 5.4.16, fresh installation of the latest staging branch.

I will dig depper into it. Also I wonder if you experience the behaviour desripted in #4922.

@test Success. I made a fresh install using a ubuntu server and it worked.

With my centos installation and a self-compiled php I faced already some other inexplicable problems during pbf14.

2 good tests. RTC. Thanks guys

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3313.

Merged into staging.