Ecto: Possible to use "text" for migration :string in Postgres instead of varchar?

[jeregrine]

Right now we have an artificial cap on "string" to varchar 255, I understand we need to be compatible with other databases but In postgres the preferred method is text.

http://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying

[ericmj]

You can pass in any atom as the migration type, so just :text would work in this case.

[jeregrine]

Ahh. Well still think it is a useful default.

On Tue, Apr 7, 2015 at 11:29 AM, Eric Meadows-Jönsson <
[email protected]> wrote:

You can pass in any atom as the migration type, so just :text would work
in this case.

Reply to this email directly or view it on GitHub
https://github.com/elixir-lang/ecto/issues/548#issuecomment-90633400.

[ericmj]

It was discussed which one to make the default and the decision was made for varchar(255) because that will work across databases.

[jeregrine]

Not sure if thats how it should be decided though? Especially when NoSQL
db's start getting added etc. Each database has different semantics...

On Tue, Apr 7, 2015 at 3:48 PM, Eric Meadows-Jönsson <
[email protected]> wrote:

It was discussed which one to make the default and the decision was made
for varchar(255) because that will work across databases.

Reply to this email directly or view it on GitHub
https://github.com/elixir-lang/ecto/issues/548#issuecomment-90728561.

[ericmj]

I agree with you. Just saying why the decision was made.

[josevalim]

The concern was not multiple databases but the fact text columns have no limit. If we have an easy way of limiting them... then i am all in.

[jeregrine]

José sorry I missed this originally. Limiting columns in the database is
less valuable IMO than limiting them at the application layer level, ie
changeset.

On Wed, Apr 29, 2015 at 9:41 AM, José Valim [email protected]
wrote:

Closed #548 https://github.com/elixir-lang/ecto/issues/548.

Reply to this email directly or view it on GitHub
https://github.com/elixir-lang/ecto/issues/548#event-293064690.

[orestis]

Just as a data point, in Postgres the Text column has identical performance than the varchar: from https://www.postgresql.org/docs/current/static/datatype-character.html

Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

I would argue that the default should be Text - however this seems like a case where the adapter should make the decision?