Aleksander Alekseev writes:
> +SELECT to_timestamp('2011-12-18 11:38 JUNK', '-MM-DD HH12:MI TZ'); --
> error
> +ERROR: invalid value "JUNK" for "TZ"
> +DETAIL: Time zone abbreviation is not recognized.
> +SELECT to_timestamp('2011-12-18 11:38 ...', '-MM-DD HH12:MI TZ'); --
> error
>
Hi,
> > Anyway, v2-0001 below is the previous patch rebased up to current
> > (only line numbers change), and then v2-0002 responds to your
> > and Daniel's review comments.
>
> LGTM.
```
+SELECT to_timestamp('2011-12-18 11:38 JUNK', '-MM-DD HH12:MI
TZ'); -- error
+ERROR: invalid value
> On 23 Jan 2024, at 23:33, Tom Lane wrote:
> Anyway, v2-0001 below is the previous patch rebased up to current
> (only line numbers change), and then v2-0002 responds to your
> and Daniel's review comments.
LGTM.
--
Daniel Gustafsson
Aleksander Alekseev writes:
> I reviewed the patch and tested it on MacOS and generally concur with
> stated above. The only nitpick I have is the apparent lack of negative
> tests for to_timestamp(), e.g. when the string doesn't match the
> specified format.
That's an excellent suggestion
Hi,
> Since I had this on my (ever-growing) TODO I re-prioritized today and took a
> look at it since I think it's something we should support.
>
> Nothing really sticks out and I was unable to poke any holes so I don't have
> too much more to offer than a LGTM.
>
> + while (len > 0)
> + {
>
Daniel Gustafsson writes:
> On 22 Jan 2024, at 03:10, Tom Lane wrote:
> + while (len > 0)
> + {
> + const datetkn *tp = datebsearch(lowtoken, zoneabbrevtbl->abbrevs,
> + zoneabbrevtbl->numabbrevs);
> My immediate reaction was that we should stop
> On 22 Jan 2024, at 03:10, Tom Lane wrote:
> I still think it would be a good idea, but I can't deny the lack
> of other interest in it. Unless someone steps up to review,
> let's close it.
Since I had this on my (ever-growing) TODO I re-prioritized today and took a
look at it since I think
Hi,
> > Hi, this patch was marked in CF as "Needs Review" [1], but there has
> > been no activity on this thread for 7+ months.
> > If nothing more is planned for this thread then it will be closed
> > ("Returned with feedback") at the end of this CF.
>
> I still think it would be a good idea,
Peter Smith writes:
> Hi, this patch was marked in CF as "Needs Review" [1], but there has
> been no activity on this thread for 7+ months.
> If nothing more is planned for this thread then it will be closed
> ("Returned with feedback") at the end of this CF.
I still think it would be a good
2024-01 Commitfest.
Hi, this patch was marked in CF as "Needs Review" [1], but there has
been no activity on this thread for 7+ months.
If nothing more is planned for this thread then it will be closed
("Returned with feedback") at the end of this CF.
==
[1]
On 6/21/23 20:07, Bruce Momjian wrote:
On Tue, Jun 13, 2023 at 12:20:42PM -0400, Tom Lane wrote:
It's annoyed me for some time that to_timestamp() doesn't implement
the TZ format code that to_char() has. I finally got motivated to
do something about that after the complaint at [1] that
On Tue, Jun 13, 2023 at 12:20:42PM -0400, Tom Lane wrote:
> It's annoyed me for some time that to_timestamp() doesn't implement
> the TZ format code that to_char() has. I finally got motivated to
> do something about that after the complaint at [1] that jsonpath's
> datetime() method can't read
It's annoyed me for some time that to_timestamp() doesn't implement
the TZ format code that to_char() has. I finally got motivated to
do something about that after the complaint at [1] that jsonpath's
datetime() method can't read typical JSON.stringify() output like
"2023-05-22T03:09:37.825Z".
13 matches
Mail list logo
