Postgres Pro
Downloads
Home   >   mailing lists

Thread: 7.2 -> 7.3 timespan, interval etc.

7.2 -> 7.3 timespan, interval etc.

From
Nabil Sayegh
Date:
Hi all,

I want to switch one of our servers to 7.3.

Some of our projects (7.2) use timespan() which for example evaluates:

SELECT timespan('5 seconds');
 interval
----------
 @ 5 secs

In 7.3 there's only interval

SELECT '5 seconds'::interval;
 interval
----------
 00:00:05

I _think_ I never used the output of timespan as a result itself, but
rather to calculate some things.
However, maybe I did (couldn't check all the projects by now).

What then ?

- Can I have the old behaviour back ?

- Is it possible to have the timespan function back, so that I dont have
to replace all occurences of timespan to interval ?

- Can I have the output of timespan in the same format as before ? (I
like the new one better, but for compatibility reasons, there could be a
case where it would be much handier with the old format)

- Why was it taken away ? Did it 'hurt' ?

- What else was taken out ?

P.S.: I just read about CREATE DOMAIN ... AS ...
Is that what I want ?
Can I tell it to have the same output as before ?

TIA
--
 e-Trolley Sayegh & John, Nabil Sayegh
 Tel.: 0700 etrolley /// 0700 38765539
 Fax.: +49 69 8299381-8
 PGP : http://www.e-trolley.de

Re: 7.2 -> 7.3 timespan, interval etc.

From
Tom Lane
Date:
Nabil Sayegh <postgresql@e-trolley.de> writes:
> Some of our projects (7.2) use timespan() which for example evaluates:
> SELECT timespan('5 seconds');
>  interval
> ----------
>  @ 5 secs

Oh?  I get

regression=# SELECT timespan('5 seconds');
 interval
----------
 00:00:05
(1 row)

in 7.0, 7.1, and 7.2.  I see this in the 7.0 release notes:

    * The date/time types datetime and timespan have been superseded by
       the SQL92-defined types timestamp and interval. Although there has
       been some effort to ease the transition by allowing PostgreSQL to
       recognize the deprecated type names and translate them to the new
       type names, this mechanism may not be completely transparent to
       your existing application.

            regards, tom lane

Re: 7.2 -> 7.3 timespan, interval etc.

From
Nabil Sayegh
Date:
Am Don, 2003-06-05 um 08.04 schrieb Tom Lane:
> Nabil Sayegh <postgresql@e-trolley.de> writes:
> > Some of our projects (7.2) use timespan() which for example evaluates:
> > SELECT timespan('5 seconds');
> >  interval
> > ----------
> >  @ 5 secs
>
> Oh?  I get
>
> regression=# SELECT timespan('5 seconds');
>  interval
> ----------
>  00:00:05
> (1 row)

Hm. Could be because of datestyle german.

> in 7.0, 7.1, and 7.2.  I see this in the 7.0 release notes:
>
>     * The date/time types datetime and timespan have been superseded by
>        the SQL92-defined types timestamp and interval. Although there has
>        been some effort to ease the transition by allowing PostgreSQL to
>        recognize the deprecated type names and translate them to the new
>        type names, this mechanism may not be completely transparent to
>        your existing application.

Do you know of more datatypes that changed ?
Is it rather more (>10) types or just the above ?

thx
--
 e-Trolley Sayegh & John, Nabil Sayegh
 Tel.: 0700 etrolley /// 0700 38765539
 Fax.: +49 69 8299381-8
 PGP : http://www.e-trolley.de

Strange Encryption Bug

From
Joanne Formoso
Date:
We are currently migrating databases from MySQL to
Postgres SQL when we noticed a weird bug in MySQL.  It
only happened once but it was strange enough to catch
our attention.  I�m very much a newbie when it comes
to databases so I can�t really diagnose errors or bugs
that well.  Anyway, for security purposes we encrypted
the ID numbers of our users in a user table.  Whenever
a transaction from that user comes in, we record the
transaction in a history table where we copy the
corresponding user ID in the history table.

For example the original user ID from the user table
is �12345abcde�.  Now the user ID that we see in the
history table became something like �12345fghijk�.

We were only able to track the specific record since
we have a time stamp and another field number given by
a secondary server that verifies the transaction.

I�m not really quite sure why this happened.  This is
the first time the bug happened with MySQL.  Any
theories why the error existed?  Can this also happen
when we migrate to Postgres SQL?

Thanks in advance!

Regards,
Joanne


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com