Re: Wrong provolatile value for to_timestamp (1 argument)

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Wrong provolatile value for to_timestamp (1 argument)
Date: 2022-07-05 14:24:16
Message-ID: 4a56e37ad9b562c263b8ad5d94938a953af17528.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2022-07-05 at 19:37 +0900, Tatsuo Ishii wrote:
> > Are you sure?  I'd say that "to_timestamp(double precision)" always
> > produces the same timestamp for the same argument.  What changes with
> > the setting of "timezone" is how that timestamp is converted to a
> > string, but that's a different affair.
>
> Of course the internal representation of timestamp with time zone data
> type is not affected by the time zone setting. But why other form of
> to_timestamp is labeled as stable? If your theory is correct, then
> other form of to_timestamp shouldn't be labeled immutable as well?

The result of the two-argument form of "to_timestamp" can depend on
the setting of "lc_time":

test=> SET lc_time = 'en_US.utf8';
SET
test=> SELECT to_timestamp('2022-July-05', 'YYYY-TMMonth-DD');
to_timestamp
════════════════════════
2022-07-05 00:00:00+02
(1 row)

test=> SET lc_time = 'de_DE.utf8';
SET
test=> SELECT to_timestamp('2022-July-05', 'YYYY-TMMonth-DD');
ERROR: invalid value "July-05" for "Month"
DETAIL: The given value did not match any of the allowed values for this field.

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-05 14:33:19 Re: Wrong provolatile value for to_timestamp (1 argument)
Previous Message Tom Lane 2022-07-05 14:24:00 Re: Making Vars outer-join aware