Aleksander Alekseev writes:
>> Anyway, attached is a revised patch that gets rid of the antique
>> code, and it produces correct results AFAICT.
> I tested your patch against the current master branch 78aa616b on
> MacOS Catalina. I have nothing to add to the patch.
Thanks. Pushed, along with
> BTW, it's customary to *not* include catversion bumps in submitted
> patches
Thanks, Tom.
> Anyway, attached is a revised patch that gets rid of the antique
> code, and it produces correct results AFAICT.
I tested your patch against the current master branch 78aa616b on
MacOS Catalina. I have
Aleksander Alekseev writes:
>>> [ timetz_zone is VOLATILE ]
>> I wasn't excited enough about it personally to change it, and I'm
>> still not --- but if you want to, send a patch.
> Here is the patch.
I looked at this patch, and felt unhappy about the fact that it left
timetz_zone() still
Hi Tom,
> No, because date_trunc depends on the current timezone setting,
> or at least its stable variants do.
Once again, many thanks for your answers!
> I wasn't excited enough about it personally to change it, and I'm
> still not --- but if you want to, send a patch.
Here is the patch.
--
John Naylor writes:
> I believe it's been discussed before that it'd be safer if pg_proc.dat had
> the same defaults as CREATE FUNCTION, and this is further evidence for that.
Yeah, maybe so. It'd make the .dat file quite a bit bigger, but maybe
less mistake-prone.
On Mon, Aug 30, 2021 at 12:58 PM Tom Lane wrote:
>
> Aleksander Alekseev writes:
> > Got it. But in this case, what's your opinion on the differences between
> > date_trunc() and timezone()? Shouldn't date_trunc() be always IMMUTABLE
as
> > well?
>
> No, because date_trunc depends on the current
Aleksander Alekseev writes:
> Got it. But in this case, what's your opinion on the differences between
> date_trunc() and timezone()? Shouldn't date_trunc() be always IMMUTABLE as
> well?
No, because date_trunc depends on the current timezone setting,
or at least its stable variants do.
Hi Tom,
Thanks for the quick reply.
> I don't see a lot of argument for treating tzdata changes differently
> from OS locale changes.
Got it. But in this case, what's your opinion on the differences between
date_trunc() and timezone()? Shouldn't date_trunc() be always IMMUTABLE as
well?
I can
I wrote:
> Aleksander Alekseev writes:
>> [ why is timetz_zone volatile? ]
Ah ... after a bit of digging in the git history, I found this [1]:
Author: Tom Lane
Branch: master Release: REL8_1_BR [35979e6c3] 2005-09-09 06:51:12 +
Given its current definition that depends on time(NULL),
Aleksander Alekseev writes:
> There are several overloaded versions of timezone() function. One
> version accepts timezone name and timestamptz and returns timestamp:
> This function is marked as IMMUTABLE and it's possible to use it in
> functional indexes. I believe it's a bug.
That's a
Hi hackers,
There are several overloaded versions of timezone() function. One
version accepts timezone name and timestamptz and returns timestamp:
=# show time zone;
TimeZone
---
Europe/Moscow
=# select timezone('MSK', '2021-08-30 12:34:56 MSK' :: timestamptz);
timezone
11 matches
Mail list logo
