| 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: | Whole Thread | Raw Message | 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
| 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 |