Re: [SQL] [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-hackers

From Yury Bokhoncovich
Subject Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date
Msg-id Pine.LNX.4.44L0.0210071153140.28879-100000@panda.center-f1.ru
Whole thread Raw
In response to Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Hello!

On Sat, 5 Oct 2002, Bruce Momjian wrote:

> 
> Yes, I agree with you Manfred, but more people _don't_ want it to
> change, and like it the way it is, so we will just keep it and add
> now("string").

IMHO the best way could be GUC-default/SET session-based variable 
controlling the behaviour. By default old Pg one, but ppl can set 
standard-compliant. Such changes were done often in past, look at "group 
by" behaviour changes 6.4->6.5, default Pg datetime representation format 
change, etc. I think those who concern interoperability confirm that it's 
much easy to add one SET per session then replace all CURRENT_STAMP to 
now(blah-blah-blah). Moreover, ppl who need old behaviour can easily 
revert to this by just one SET (in case GUC is set to new behaviour).

> 
> Added to TODO:
> 
>     * Add now("transaction|statement|clock") functionality
> 
> I have attached an SGML patch that explains the issues with
> CURRENT_TIMESTAMP in more detail.

-- 
WBR, Yury Bokhoncovich, Senior System Administrator, NOC of F1 Group.
Phone: +7 (3832) 106228, ext.140, E-mail: byg@center-f1.ru.
Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: pg_filedump
Next
From: Bruce Momjian
Date:
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP