Ø I believe, i have found the cause of this. This is due to "VALID UNTIL '1969-12-31 00:00:00';" option. For confirming this, do you mind to do the following steps once again and let me know the status.
Yup. That did it!
I told you it was something idiotically stupid that I just wasn’t understanding properly. Having already used the xkcd joke on password strength, (http://xkcd.com/936/), I can now say that this has been an “Epoch Fail” on my part. (http://xkcd.com/376/)
This is an example of a little knowledge being a dangerous thing. Knowing that UNIX time began ‘1970-01-01 00:00:00’, and knowing what happens when you add 1 to a signed two byte integer variable that had been set to 32,767, I figured that 1970-01-01 minus 1 day would automatically overflow to the end of UNIX time and therefore be synonymous with infinity for practical purposes. So I just decided that VALID UNTIL '1969-12-31 00:00:00' must be exactly the same as VALID UNTIL 'infinity', because any other implementation would be too silly to merit thinking about.
I may not have been far off.
It occurred to me that I was also probably not so silly as to change the expiration setting in the pgAdmin UI, so I created another user and paid attention to the expiration control under the password setting text boxes. When the user was created, it defaulted to infinity, and this was represented by the expiration date being the current date and the checkbox beside it being off. When I went back to alter that now existing user, it showed that the expiration date was 1969-12-31.
So my diagnosis is that the Windows 8 programmers have left you an adorable little present and the code you used to read and interpret the infinity end date and render it in the interface in Windows 7 is causing the pgAdmin interface to see an expiration set to infinity as UNIX Epoch Start Date -1 day in Windows 8. And the SQL writing engine is recognizing this as an alteration and treating it as such.
