Re: missed features and unhappy changes when pg 7.1->7.2
От | Jeff Davis |
---|---|
Тема | Re: missed features and unhappy changes when pg 7.1->7.2 |
Дата | |
Msg-id | 200209200025.51489.list-pgsql-general@empires.org обсуждение исходный текст |
Ответ на | missed features and unhappy changes when pg 7.1->7.2 (Yury Bokhoncovich <byg@center-f1.ru>) |
Ответы |
Re: missed features and unhappy changes when pg 7.1->7.2
Re: missed features and unhappy changes when pg 7.1->7.2 |
Список | 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.
В списке pgsql-general по дате отправления: