Re: missed features and unhappy changes when pg 7.1->7.2

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.

In response to

Responses

Browse pgsql-general by date

  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