Re: Bad timestamp external representation

From: Mark Tessier <m_tessier(at)sympatico(dot)ca>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Bad timestamp external representation
Date: 2003-04-29 21:28:55
Message-ID: 20030429172855.6ad04f1c.m_tessier@sympatico.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 29 Apr 2003 20:18:40 +0100 (BST)
"Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)uk> wrote:

> On Tue, 29 Apr 2003, Mark Tessier wrote:
>
> > On Tue, 29 Apr 2003 00:02:20 -0400
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > > Mark Tessier <m_tessier(at)sympatico(dot)ca> writes:
> > > > Actually, that was the last thing I tried before I wrote this note. Before I entered
> > >
> > > > herboris=> INSERT INTO cart (cartid, clientid, invdate, paydate) VALUES
> > > > herboris-> (4469858, 2, 'current', 'now');
> > > > And still got the same error message:
> > > > ERROR: Bad date external representation 'current'
> > >
> > > 'now' is the only accepted spelling.
> > >
> > > ('current' used to mean something subtly different from 'now', but that
> > > meaning isn't supported anymore.)
> >
> > I should have mentioned that I'm using version 7.3. As a result of using version 7.3, I'm beginning to realize that my "Practical Postgresql" book isn't quite up to date. The reason I want to use current timestamp constant is because it allows me to calculate the elapsed time between current and now constants (current - now = elapsed_time_in_days) According to the book, "If you watch the...row with the current timestamp, you'll notice it changes in each query to show the updated system time...".(pg. 81). Anyway, since the "current" meaning isn't supported anymore, how would I go about calculating the amount of time (in days) that has elapsed since inserting or updating a field with the initial date.
> >
> > Thanks for your help,
> >
> > Mark Tessier
>
> I think you may need to explain to us again what you are trying to achieve
> because to insert a record you'd use something like:
>
> INSERT INTO cart (cartid, clientid, invdate, paydate)
> VALUES (4469856, 2, current_timestamp, NULL);
>
> to update it you'd use:
>
> UPDATE cart SET paydate = current_timestamp WHERE cartid = 4469856;
>
> and to find out how long it took to be paid and how long ago that was from
> current time you'd use:
>
> SELECT paydate - invdate, current_timestamp - invdate
> FROM cart
> WHERE cartid = 4469856;
>
>
> The subtle difference that was mentioned was that one timestamp was set at the
> start of a transaction and the other was the real current timestamp.

In the same book (pg. 81), the author explainsh: "...current will always tell you the "current" time when queried, regardless of when it was stored to the table."

The example he gives:

CREATE TABLE tasklog
(taskname char(15),
timebegun timestamp,
timefinished timestamp);

INSERT INTO tasklog VALUES
('delivery', 'now', 'current');

INSERT INTO tasklog VALUES
('remodeling', 'now', 'current');

SELECT taskname, timefinished - timebegun AS timespent FROM tasklog;

taskname | timespent
-----------------------
delivery | 00:15:32
remodeling| 00:04:42

I guess the way he's doing it saves the step of having to UPDATE the row before doing the SELECT calculation. Actually, I was implementing something along the lines of your suggestion since 'current' now seems to be deprecated.
>
> From the sounds of it you're expecting to start a transaction and keep it open
> for days, that doesn't seem right.

Yes, for a given customer who pays by cheque, I want to set the start date and leave the paydate NULL. This way I can find out how many days have gone by since the invoice date. To do this I would:

Determine if paydate = NULL
If yes, UPDATE paydate with 'current-timestamp'
Do the SELECT calculation to get the number of days since invdate was set
UPDATE paydate with NULL again
When the cheque is received, I would permanently update paydate with NULL.

I hope I'm not being too verbose. In any case it helps me set it straight by having to write it down.

If you, by any chance, have a better suggestion, I would be happy to hear it.

Mark Tessier

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-04-29 22:27:20 Re: qsort (was Re: Solaris) (fwd)
Previous Message Jim C. Nasby 2003-04-29 21:05:40 Re: > 16TB worth of data question