I fear that I'm about to embarrass myself again. So I'll just ask for forgiveness in advance. Here's a simple test to get started. (All tests are done in a session where I set the timezone to 'UTC'.) drop function if exists f(text) cascade; drop function if exists f(timestamp) cascade; drop function if exists f(timestamptz) cascade; create function f(t in text) returns text language plpgsql as $body$ begin return 'plain "text" overload: '||t; end; $body$; select f('2021-03-15'::date); This causes the 42883 error, "function f(date) does not exist". I might've expected the system to have done an implicit conversion to "text" because this conversion is supported, thus: select f(('2021-03-15'::date)::text); This succeeds with this result: plain "text" overload: 2021-03-15 There's clearly a rule at work here. For some reason, the implicit conversion from "date" to "text" is not considered to be acceptable. Now add a plain "timestamp" overload and repeat the test: create function f(t in timestamp) returns text language plpgsql as $body$ begin return 'plain "timestamp" overload: '||t::text; end; $body$; select f('2021-03-15'::date); This succeeds with this result: plain "timestamp" overload: 2021-03-15 00:00:00 So there's a different rule at work here. For some reason, the implicit conversion from "date" to plain "timestamp" _is_ considered to be acceptable. Now add a "timesatmptz" overload and repeat the test: create function f(t in timestamptz) returns text language plpgsql as $body$ begin return '"timestamptz" overload: '||t::text; end; $body$; select f('2021-03-15'::date); This succeeds with this result: "timestamptz" overload: 2021-03-15 00:00:00+00 For some reason, the implicit conversion from "date" to "timestamptz" _is_ considered to be preferable to the implicit conversion from "date" to plain "timestamp". I started with "38.6. Function Overloading", followed the link to "Chapter 10. Type Conversion" and started with "10.3. Functions". I read "If no exact match is found, see if the function call appears to be a special type conversion request…" as far as "Note that the “best match” rules are identical for operator and function type resolution." So I went to "10.2. Operators" and searched in the page for "timestamp". No hits. Where, in the PG doc, can I find a statement of the rules that allow me to predict the outcome of my tests? |