Re: Looking for a doc section that presents the overload selection rules

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Looking for a doc section that presents the overload selection rules
Date: 2021-10-22 18:16:42
Message-ID: CAKFQuwbMJwt5gfKV+m+pTRFSAw66s8+Dpf-3hw6M-JN+p-HqXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Friday, October 22, 2021, Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:
>
> There could, so easily, have been three “to_char()” overloads for these
> three data types that honored the spirit of the “::text” typecast by
> rendering only what’s meaningful, despite what the template asks for.
>

Even if we added to_char(date…) having it produce output “despite what the
template asks for” is going to be questionable. At least this way we are
honest about what we are doing - if you don’t want non-date stuff in the
output don’t have it in the template. Unless the behavior is going to
differ from what you can get today adding a new function doesn’t have a
benefit. It’s unclear whether having different behavior is desirable.

The argument about avoiding the implicit cast, and thus being easier for
newcomers to figure out, is the compelling one for me. But, frankly, “it
just works” applies here - I’ve seen little evidence that there is a
meaningful usability issue in the community.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bryn Llewellyn 2021-10-22 18:39:50 Re: Looking for a doc section that presents the overload selection rules
Previous Message Rob Sargent 2021-10-22 18:16:14 Re: Looking for a doc section that presents the overload selection rules