Handle default values for datetime/datetimetz columns in PostgreSQL

[sarcher]

(This was originally in #670 but am re-submitting due to a busted merge)

When dealing with legacy schema it would be nice to be able to map default values and not have the schema spit out ALTER statements each time. This works correctly today for basic integer and string columns, but does not handle columns with special types such as boolean or datetime.

For example, the following statement:

ALTER TABLE test_table ALTER test_column SET DEFAULT CURRENT_TIMESTAMP;

Results in a column definition like:

test_column | timestamp with time zone | not null default now()

However, repeating the same schema generation will result in the same ALTER statement each time, because it will always detect that the default value has changed. The same is true for boolean columns.

This simple change prevents this situation from happening and correctly detects that the column default has not changed. It is specific to PostgreSQL.

[doctrinebot]

Hello,

thank you for creating this pull request. I have automatically opened an issue
on our Jira Bug Tracker for you. See the issue link:

http://www.doctrine-project.org/jira/browse/DBAL-1131

We use Jira to track the state of pull requests and the versions they got
included in.

[sarcher]

@Ocramius re-submitted as requested; thanks and sorry for the problems!

[Ocramius]

thanks and sorry for the problems!

What problems? ;-)

[Ocramius]

I don't see now() in the test cases: is it a missing test?

[sarcher]

It is kind of subtle; the tests will create a new table using the mapping of CURRENT_TIMESTAMP, and then the schema manager will call listTableDetails() on the database itself, which will report the column as having a default of now() (e.g. not null default now()). So the actual change in this PR is recognizing that "now()" is the same as the platform's getCurrentTimestampSQL().

The reason the tests must use CURRENT_TIMESTAMP and not NOW() is that it must match what is in AbstractPlatform::getCurrentTimestampSQL().

[sarcher]

Just wanted to check up on this to see if there was anything else needed of me on it -- it's on my open to do list. :)

[Ocramius]

@sarcher I think this just needs a rebase. Assigning to @deeky666 for merging when he has time

[sarcher]

@deeky666 I have rebased this to the current master, and I think it is ready for merging. Note that I did need to add an explicit $conncetion->close(); to an existing unrelated test in order for the PostgreSQL tests to work outside of process isolation, which is needed until #849 is merged.

During testing the rebase I also logged DBAL-1274 as I realized that all of the Travis builds seemed to be testing against PostgreSQL 9.4. I proposed a fix in there, but not sure of the impact.

[morozov]

Closing as stale.