> They then also show that there is in fact a significant performance difference when you need to migrate your schema to accodomate a change in length of strings being stored.
Which is a pointless demonstration if you RTFM and design your schema correctly, using text, just like the manual and the wiki tells you to.
> the text type with CHECK constraint allows you to evolve the schema easily compared to character varying or varchar(n) when you have length checks.
Which is exactly what the manual tells you ....
"For many purposes, character varying acts as though it were a domain over text"
And what is wrong with someone figuring out for themselves and explaining to others why some suggestion makes sense logically, rather than just quoting the manual?
> And what is wrong with someone figuring out for themselves....
Whatever floats your boat, of course.
However, the Postgres manual is amongst the best written and most comprehensive in the industry.
Therefore wasting your time proving the Postgres documentation is correct is, well, a rather interesting hobby.
And if I'm expected to read waffle on someone's blog post, I would rather they tell me something I do not know, and not something obvious that is already very clearly and comprehensively stated in a million places, whether the manual, the wiki or elsewhere.
Finally, as I said, its old, VERY old news. So its not even like the author is highlighting something brand-new in the latest release. Its been that way basically forever at this stage.
Which is a pointless demonstration if you RTFM and design your schema correctly, using text, just like the manual and the wiki tells you to.
> the text type with CHECK constraint allows you to evolve the schema easily compared to character varying or varchar(n) when you have length checks.
Which is exactly what the manual tells you ....
"For many purposes, character varying acts as though it were a domain over text"