Re: Bad timestamp external representation - Mailing list pgsql-general

From Mark Tessier
Subject Re: Bad timestamp external representation
Date
Msg-id 20030429172855.6ad04f1c.m_tessier@sympatico.ca
Whole thread Raw
In response to Re: Bad timestamp external representation  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List pgsql-general
On Tue, 29 Apr 2003 20:18:40 +0100 (BST)
"Nigel J. Andrews" <nandrews@investsystems.co.uk> wrote:

> On Tue, 29 Apr 2003, Mark Tessier wrote:
>
> > On Tue, 29 Apr 2003 00:02:20 -0400
> > Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > > Mark Tessier <m_tessier@sympatico.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
allowsme to calculate the elapsed time between current and now constants (current - now = elapsed_time_in_days)
Accordingto the book, "If you watch the...row with the current timestamp, you'll notice it changes in each query to
showthe updated system time...".(pg. 81). Anyway, since the "current" meaning isn't supported anymore, how would I go
aboutcalculating 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,
regardlessof 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,
Iwas 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
findout 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


pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: > 16TB worth of data question
Next
From: Tom Lane
Date:
Subject: Re: qsort (was Re: Solaris) (fwd)