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

Hello!

On Fri, 20 Sep 2002, Jeff Davis wrote:

>
> 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

Yep. Quik alter fixed all. But it costs me a lot nervos.:( Luckly I had
spare way to store info in the file. So, do you know where to dig?8)

> 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 */

Hm...I meant commands like this:

"UPDATE ${acct_table1} SET AcctStopTime='%S',
AcctSessionTime=\"interval\"(\"timestamp\"('%S') - AcctStartTime),
AcctTerminateCause='%{Acct-Terminate-Cause}', AcctStopDelay =
%{Acct-Delay-Time} WHERE AcctSessionTime=NULL AND AcctStopTime=NULL AND
NASIPAddress= '%{NAS-IP-Address}' AND AcctStartTime <= '%S';

Looks weird for me now but it works.

pure interval and timestamp gave errors for a known reason.

> > (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.

--
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg(at)center-f1(dot)ru(dot)
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.