This is the main PostgreSQL git repository. http://git.postgresql.org/cgit/postgresql.git/atom?h=master 2026-05-13T14:34:17Z 2026-05-13T14:34:17Z Tom Lane 2026-05-13T14:34:17Z urn:sha1:020794ee42a3413b416898e7931a8a3a5b43e9ab Update typedefs.list from the buildfarm, and run pgindent. The changes from the new typedefs list are pretty minimal, since we'd been pretty good (not perfect) about updating typedefs.list by hand. But the pgindent behavior changes installed by a3e6beba6, b518ba4af, and 60f9467c3 add up to make this a relatively sizable diff. 2026-01-01T18:24:10Z Bruce Momjian 2026-01-01T18:24:10Z urn:sha1:451c43974f8e199097d97624a4952ad0973cea61 Backpatch-through: 14 2025-01-16T19:11:19Z Tom Lane 2025-01-16T19:11:19Z urn:sha1:d7674c9fab09d5bab427ba3b9b7a20b169aba715 If a time zone abbreviation used in datetime input is defined in the currently active timezone, use that definition in preference to looking in the timezone_abbreviations list. That allows us to correctly handle abbreviations that have different meanings in different timezones. Also, it eliminates an inconsistency between datetime input and datetime output: the non-ISO datestyles for timestamptz have always printed abbreviations taken from the IANA data, not from timezone_abbreviations. Before this fix, it was possible to demonstrate cases where casting a timestamp to text and back fails or changes the value significantly because of that inconsistency. While this change removes the ability to override the IANA data about an abbreviation known in the current zone, it's not clear that there's any real use-case for doing so. But it is clear that this makes life a lot easier for dealing with abbreviations that have conflicts across different time zones. Also update the pg_timezone_abbrevs view to report abbreviations that are recognized via the IANA data, and *not* report any timezone_abbreviations entries that are thereby overridden. Under the hood, there are now two SRFs, one that pulls the IANA data and one that pulls timezone_abbreviations entries. They're combined by logic in the view. This approach was useful for debugging (since the functions can be called on their own). While I don't intend to document the functions explicitly, they might be useful to call directly. Also improve DecodeTimezoneAbbrev's caching logic so that it can cache zone abbreviations found in the IANA data. Without that, this patch would have caused a noticeable degradation of the runtime of timestamptz_in. Per report from Aleksander Alekseev and additional investigation. Discussion: https://postgr.es/m/CAJ7c6TOATjJqvhnYsui0=CO5XFMF4dvTGH+skzB--jNhqSQu5g@mail.gmail.com 2025-01-01T16:21:55Z Bruce Momjian 2025-01-01T16:21:55Z urn:sha1:50e6eb731d98ab6d0e625a0b87fb327b172bbebd Backpatch-through: 13 2024-01-25T22:47:08Z Tom Lane 2024-01-25T22:47:08Z urn:sha1:8ba6fdf905d0f5aef70ced4504c6ad297bfe08ea Formerly, these were only supported in to_char(), but there seems little reason for that restriction. We should at least have enough support to permit round-tripping the output of to_char(). In that spirit, TZ accepts either zone abbreviations or numeric (HH or HH:MM) offsets, which are the cases that to_char() can output. In an ideal world we'd make it take full zone names too, but that seems like it'd introduce an unreasonable amount of ambiguity, since the rules for POSIX-spec zone names are so lax. OF is a subset of this, accepting only HH or HH:MM. One small benefit of this improvement is that we can simplify jsonpath's executeDateTimeMethod function, which no longer needs to consider the HH and HH:MM cases separately. Moreover, letting it accept zone abbreviations means it will accept "Z" to mean UTC, which is emitted by JSON.stringify() for example. Patch by me, reviewed by Aleksander Alekseev and Daniel Gustafsson Discussion: https://postgr.es/m/1681086.1686673242@sss.pgh.pa.us 2024-01-04T01:49:05Z Bruce Momjian 2024-01-04T01:49:05Z urn:sha1:29275b1d177096597675b5c6e7e7c9db2df8f4df Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12 2023-03-17T21:47:19Z Tom Lane 2023-03-17T21:47:15Z urn:sha1:3e59e5048d0f20debe4ad79b2e02ca2a76c5daed We already had five copies of essentially the same logic, and an upcoming patch introduces yet another use-case. That's past my threshold of pain, so introduce a common subroutine. There's not that much net code savings, but the chance of typos should go down. Inspired by a patch from Przemysław Sztoch, but different in detail. Discussion: https://postgr.es/m/01a84551-48dd-1359-bf7e-f6b0203a6bd0@sztoch.pl 2023-01-02T20:00:37Z Bruce Momjian 2023-01-02T20:00:37Z urn:sha1:c8e1ba736b2b9e8c98d37a5b77c4ed31baf94147 Backpatch-through: 11 2022-12-09T21:07:49Z Tom Lane 2022-12-09T21:07:49Z urn:sha1:c60488b4748b4316f1c92d62457671046e5c8994 This patch converts the input functions for date, time, timetz, timestamp, timestamptz, and interval to the new soft-error style. There's some related stuff in formatting.c that remains to be cleaned up, but that seems like a separable project. Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru 2022-12-09T18:30:47Z Tom Lane 2022-12-09T18:30:43Z urn:sha1:2661469d862239ea8b9e3a1cf5352d833f6f0fec Pay down some ancient technical debt (dating to commit 022fd9966): fix a couple of places in datetime parsing that were throwing ereport's immediately instead of returning a DTERR code that could be interpreted by DateTimeParseError. The reason for that was that there was no mechanism for passing any auxiliary data (such as a zone name) to DateTimeParseError, and these errors seemed to really need it. Up to now it didn't matter that much just where the error got thrown, but now we'd like to have a hard policy that datetime parse errors get thrown from just the one place. Hence, invent a "DateTimeErrorExtra" struct that can be used to carry any extra values needed for specific DTERR codes. Perhaps in the future somebody will be motivated to use this to improve the specificity of other DateTimeParseError messages, but for now just deal with the timezone-error cases. This is on the way to making the datetime input functions report parse errors softly; but it's really an independent change, so commit separately. Discussion: https://postgr.es/m/3bbbb0df-7382-bf87-9737-340ba096e034@postgrespro.ru