Re: [GENERAL] CURRENT_TIMESTAMP

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] CURRENT_TIMESTAMP
Дата
Msg-id 12393.1032873985@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] CURRENT_TIMESTAMP  (Manfred Koizar <mkoi-pg@aon.at>)
Ответы Re: [GENERAL] CURRENT_TIMESTAMP
Список 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 по дате отправления:

Предыдущее
От: Christoph Haller
Дата:
Сообщение: Re: [GENERAL] CURRENT_TIMESTAMP
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: arrays (was untitled)