From: | Jeff Davis <list-pgsql-general(at)empires(dot)org> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: missed features and unhappy changes when pg 7.1->7.2 |
Date: | 2002-09-20 07:25:51 |
Message-ID: | 200209200025.51489.list-pgsql-general@empires.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
A fair number of people were a little bugged about the change from silent
truncation to throwing an error, including me.
I wasn't so much bothered by the change, but rather that it wasn't in the
migration notes. Unfortunatly it turned up a few lazy programmer mistakes
amongst my colleagues and I. No big problem for me though, I changed the
atttypmod attribute of the pg_attribute system catalog for the problem
attributes, thereby putting off my work a little longer ;)
For the date thing, you can do:
SELECT datetime '01/01/01 01:01:01';
or SELECT datetime('01/01/01 01:01:01');
or SELECT timestamp '01/01/01 01:01:01';
/* the last one returns a timezonetz type though */
I suppose it depends on your needs, but I think those will work mostly the
same.
Regards,
Jeff
On Friday 20 September 2002 12:08 am, Yury Bokhoncovich wrote:
> Hello!
>
> Maybe I missed something but what are reasons to change behaviour in 7.2
> in comparison with 7.1?
> I mean that early PG just truncated the rest (tail) of extra long string
> (i.e. where len(string)>char(this attr) but insert the head. Now inserting
> fails. Is it tunable somewhere in GUC so I could revert to old behaviour?
>
> And yet, what is the Right Way to deal with timestamp?
> Now I'm using Thomas's recipe \"timestamp\" but it loooks wierd and bad.
From | Date | Subject | |
---|---|---|---|
Next Message | Timur V. Irmatov | 2002-09-20 07:57:07 | BYTEA |
Previous Message | Jeff Davis | 2002-09-20 07:13:30 | Re: Problems with Triggers |