Re: [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-sql

From Tom Lane
Subject Re: [GENERAL] CURRENT_TIMESTAMP
Date
Msg-id 12393.1032873985@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] CURRENT_TIMESTAMP  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: [GENERAL] CURRENT_TIMESTAMP  ("Josh Berkus" <josh@agliodbs.com>)
List pgsql-sql
Manfred Koizar <mkoi-pg@aon.at> writes:
> On Mon, 23 Sep 2002 13:36:59 -0700, Josh Berkus <josh@agliodbs.com>
> wrote:
>> Ideally, since we get this question a lot, that a compile-time or 
>> execution-time switch to change the behavior of current_timestamp 
>> contextually would be nice.

> Yes, GUC!

I think a GUC variable is overkill, in fact potentially dangerous
(what if it's been changed without your app noticing)?  I'm fine with
changing current_timestamp to be start-of-current-interactive-command,
though I'd not want to try to chop it more finely than that, for the
reasons already discussed.  But I strongly feel that we should leave
the historical behavior of now() alone.  There is no spec-based argument
for changing now(), since it isn't in the spec, and its behavior has
been set *and documented* in Postgres since Berkeley days.

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

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 ...
        regards, tom lane


pgsql-sql by date:

Previous
From: Christoph Haller
Date:
Subject: Re: [GENERAL] CURRENT_TIMESTAMP
Next
From: Stephan Szabo
Date:
Subject: Re: arrays (was untitled)