Re: Patch: shouldn't timezone(text, timestamp[tz]) be STABLE?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-09-06T15:49:12Z
Lists: pgsql-hackers
Aleksander Alekseev <aleksander@timescale.com> 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 a quick-and-dirty patch to resolve the DYNTZ problem in the back branches. >> I'm fairly unhappy now that we don't have any >> regression test coverage for this function. > Yep, that's unfortunate. I see several tests for `AT TIME ZONE` > syntax, which is a syntax sugar to timezone() with timestamp[tz] > arguments. But considering how `timetz` type is broken in the first > place [1], I'm not surprised few people feel motivated to do anything > related to it. Do you think there is a possibility that one day we may > be brave enough to get rid of this type? I'm afraid not, seeing that it's required by the SQL standard. I thought about adding tests based on the CLT example I showed upthread, and just accepting the need for two variant result files. Maybe we should do that. However, it still wouldn't be a great test, because it would not prove that the DST switchover happens at the right time of year, or indeed at all. So for the moment I didn't. regards, tom lane
Commits
-
Fix actively-misleading comments about the contents of struct pg_tm.
- 89dba59590fd 15.0 landed
-
Fix bogus timetz_zone() results for DYNTZ abbreviations.
- eb3c8d24808a 12.9 landed
- d8a266c5e1bd 13.5 landed
- b28c862a6c11 10.19 landed
- 90b4647f63da 11.14 landed
- 599c73a91a04 14.0 landed
- 5907c3818c43 9.6.24 landed
-
Make timetz_zone() stable, and correct a bug for DYNTZ abbreviations.
- 388e71af880d 15.0 landed