| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | Chris Bandy <bandy(dot)chris(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Unexpected casts while using date_trunc() |
| Date: | 2018-05-24 19:31:33 |
| Message-ID: | 915.1527190293@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> Yeah. There are two relevant variants of date_trunc():
> [...]
> Tom> So we probably ought to change the docs here.
> There's also the option of adding an explicit function
> date_trunc(text,date) returns date, which is a workaround that I (and
> probably quite a few other people) have used. I think having such a
> function added to core would be less surprising than the current
> behavior.
Ah! Yes, of course, that would be better. Seems like a workable
solution for Chris, too. We still can't back-patch it, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pierre-Emmanuel André | 2018-05-24 19:47:27 | PostgreSQL 11 beta1 : regressions failed on OpenBSD with JIT |
| Previous Message | Tom Lane | 2018-05-24 19:30:03 | contrib/sepgsql fails on Fedora 28 |