On Sat, Jun 13, 2015 at 6:24 PM, Bruce Momjian <br...@momjian.us> wrote: >> I think we should really address this. Attached patch adds a new >> release note item for it. It also adds to the documentation that >> explains why users should prefer varchar(n)/text to character(n); the >> lack of abbreviated key support now becomes a huge disadvantage for >> character(n), whereas in previous versions the disadvantages were >> fairly minor. >> >> In passing, I updated the existing sort item to reflect that only >> varchar(n), text, and numeric benefit from the abbreviation >> optimization (not character types more generally + numeric), and added >> a note on the effectiveness of the abbreviation optimization alone. > > This all also seems like overkill to me. Users just don't care about > this level of detail, and are easily confused by it.
Really? The pre-check thing wasn't too complex for Magnus to have a couple of bullet points on it *specifically* in his high level NYC talk on Postgres 9.5 features [1]. I don't think it's hard to understand at all. Also, it's simply incorrect to describe abbreviation as: "Improve the speed of sorting character and numeric fields". Character fields presumably include character(n), and as I pointed out character(n) lacks abbreviation support. That needs to be documented as an additional disadvantage of character(n) vs text/varchar(n) in the documentation where the trade-off is already discussed (i.e. not in the release notes), because it makes a *huge* difference. And ISTM that it should also be clear from the release notes themselves. We seemingly always have <type> </type> tags when types are named in release notes. [1] http://www.hagander.net/talks/postgresql95.pdf -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
