pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Josh Berkus <josh@agliodbs.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Manfred Koizar <mkoi-pg@aon.at>
Cc: josh@agliodbs.com, Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Aaron Held <aaron@MetroNY.com>
Cc: Roberto Mello <rmello@cc.usu.edu>
Cc: Neil Conway <neilc@samurai.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: [GENERAL] CURRENT_TIMESTAMP
Date: Tue, 24 Sep 2002 08:05:59 -0700
Message-ID: <web-1658838@davinci.ethosmedia.com> (raw)
In-Reply-To: <12393.1032873985@sss.pgh.pa.us>

Tom,

> If we leave now() alone then there's no need to create another
> non-spec-compliant syntax like 'transaction_timestamp', either.
> (I really don't want to see us do that, because without parens
> it would mean making a new, not-in-the-spec fully-reserved word.)

So, if I've got this straight:

-- current_timestamp will return the timestamp for the beginning of the
SQL statement.

-- now() will return the timestamp for the beginning of the
transaction.

-- timeofday() will return the timestamp of the exact time the function
is called.

... thus changing only current_timestamp.

This looks fine to me, as a search-and-replace on current_timestamp is
easy.   However, we need to do a better job of warning people about the
change than we did with interval() to "interval"().   

Actually, can I make the proposal that *any* change that breaks
backward compatibility be mentioned in both the new version
announcement and on the download page?   This would prevent a lot of
grief.   If I'm kept informed of these changes, I'll be happy to write
up a user-friendly announcement/instructions on how to cope with the
change.

> BTW, as long as we are dorking with the current-time family, does
> anyone want to vote for changing timeofday() to return a timestamptz
> instead of a text string?  There's no good argument except slavish
> backward compatibility for having it return text, and we seem to be
> quite willing to ignore backwards compatibility in this thread ...

No, I don't see any reason to do this.  It's not like timeofday() is a
particularly logical name, anyway.   Why not introduce a new function,
rightnow(), that returns timestamptz?

Better yet, how about we introduce a parameter to now()?   Example:

now() or now('transaction') returns the transaction timestamp.
now('statement') returns the statement timestamp
now('immediate') returns the timestamp at the exact time the function
is called.

This would seem to me much more consistent than having 3 different
time-calls, whose names have nothing to do with the difference between
them.  And it has the advantage of not breaking backward compatibility.

We could introduce the new version of now() in 7.4, encourage everyone
to use it instead of other timestamp calls, and then in 7.5 change the
behavior of current_timestamp for SQL92 compliance.

-Josh Berkus




view thread (61+ messages)  latest in thread

Message-ID: <web-1658838@davinci.ethosmedia.com>
Permalink:  ../web-1658838@davinci.ethosmedia.com/
Also on:    postgresql.org/message-id/web-1658838@davinci.ethosmedia.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: josh@agliodbs.com, tgl@sss.pgh.pa.us, mkoi-pg@aon.at, pgman@candle.pha.pa.us, aaron@MetroNY.com, rmello@cc.usu.edu, neilc@samurai.com
  Subject: Re: [GENERAL] CURRENT_TIMESTAMP
  In-Reply-To: <web-1658838@davinci.ethosmedia.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox