support array type for #150

[lirispp]

Add Array type column for PostgreSQL.

[Tapac]

Thank you for PR.
Could you please add some tests to ensure that arrays will work on every DBMS (AFAIK MySQL doesn't support ARRAY column type)?

[frellan]

How is it going with this? 😄

[Drako]

@lirispp @saibotma as @Tapac said, tests would be really nice to have. Yet I do not fully understand this "will work on every DBMS" mentality.

I don't exactly see, why it would be so bad to say "If you want to use this specific feature you need one of these DBMS..." Especcially as emulating the behaviour in software usually yields suboptimal results.

[MrPowerGamerBR]

I agree with @Drako, why Exposed needs to be based on the DBMS that has less supported features?

What I ended up doing is copying @lirispp's code to my project while this PR isn't merged, you don't really need to fork Exposed to add array support to it, but having it on Exposed would be great.

[MrPowerGamerBR]

By the way, this PR has issues with DAO objects.

	val stored = transaction(database) {
		SchemaUtils.createMissingTablesAndColumns(StoredMessages)
		StoredMessage.new(id) {
			authorId = 0
			channelId = 1
			content = "owo"
			createdAt = System.currentTimeMillis()
			storedAttachments = arrayOf("owo")
		}
	}

	transaction(database) {
		stored.storedAttachments = arrayOf("hello world")
	}

This causes an Exception in thread "main" java.lang.IllegalStateException: Array does not support for this database, to fix this, an

		if (value is Array<*>) {
			return value
		}

needs to be added to the valueFromDB method.

And, of course, Array does not support for this database is not correct, right? Shouldn't it be This DBMS doesn't support arrays?

[Savrov]

So will this branch merged to master?

[Tapac]

@Drako, @MrPowerGamerBR , I just mean that if you add a feature to a framework which works with different DBMS you have to implement it for every DBMS where it's possible and throw Unsupported exception for others.
Otherwise, users who know what e.g. Arrays supported by Oracle will end up with unworking code.

Also, I see a lack of type-safety in provided operators (any/contains).

Adding specific features will be much easier after splitting Exposed to modules (see p.2 here)