CVSROOT:        /cvsroot
Module name:    pgsql-server
Changes by:     [EMAIL PROTECTED]       04/04/10 15:02:59

Modified files:
        doc/src/sgml   : func.sgml 
        src/backend/utils/adt: timestamp.c 
        src/test/regress/expected: date.out 
        src/test/regress/sql: date.sql 

Log message:
        Please find a small patch to fix the brain damage "century" and
        "millennium" date part implementation in postgresql, both in the code
        and the documentation, so that it conforms to the official definition.
        If you do not agree with the official definition, please send your
        complaint to "[EMAIL PROTECTED]". I'm not responsible for them;-)
        
        With the previous version, the centuries and millenniums had a wrong
        number and started the wrong year. Moreover century number 0, which does
        not exist in reality, lasted 200 years. Also, millennium number 0 lasted
        2000 years.
        
        If you want postgresql to have it's own definition of "century" and
        "millennium" that does not conform to the one of the society, just give
        them another name. I would suggest "pgCENTURY" and "pgMILLENNIUM";-)
        
        IMO, if someone may use the options, it means that postgresql is used for
        historical data, so it make sense to have an historical definition. Also,
        I just want to divide the year by 100 or 1000, I can do that quite easily.
        
        BACKWARD INCOMPATIBLE CHANGE
        
        Fabien Coelho - [EMAIL PROTECTED]


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to