From: Tom Lane <tgl@sss.pgh.pa.us>
To: Corey Huinker <corey.huinker@gmail.com>
cc: Jeff Janes <jeff.janes@gmail.com>,
 Richard Wesley <richard@duckdblabs.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Query generates infinite loop
In-reply-to: 
 <CADkLM=fHZezdmrCx0mpB69UemH=frCTkyLVcs4dZ2p1b1hMh4w@mail.gmail.com>
References: <91B44E7B-68D5-448F-95C8-B4B3B0F5DEAF@duckdblabs.com>
 <CAFj8pRDzVzTfsnxs_T9T7k=HW_gWCryo==rVB-AX4R6pXo85xQ@mail.gmail.com>
 <2842828.1650474225@sss.pgh.pa.us> <3010353.1650490989@sss.pgh.pa.us>
 <CAMkU=1yp1S5cwj_e762D_tNHT5w=ZKDB3k6UCmSaTkbnddSwOA@mail.gmail.com>
 <CADkLM=dDM4TjiiBop4JWKz0jGk-XRX1nAovQd5cmzTODNbCr-g@mail.gmail.com>
 <3603504.1652068977@sss.pgh.pa.us>
 <CADkLM=dF+c2mGub1-tTK9c7OJSdK8ZdNZMURmcH8rydDcdpcyA@mail.gmail.com>
 <3817754.1652114564@sss.pgh.pa.us>
 <CADkLM=fHZezdmrCx0mpB69UemH=frCTkyLVcs4dZ2p1b1hMh4w@mail.gmail.com>
Comments: In-reply-to Corey Huinker <corey.huinker@gmail.com>
	message dated "Tue, 10 May 2022 19:24:15 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24871.1652226152.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 May 2022 19:42:32 -0400
Message-ID: <24872.1652226152@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/24872.1652226152%40sss.pgh.pa.us>
Precedence: bulk

Corey Huinker <corey.huinker@gmail.com> writes:
>> Less sure about that.  ISTM the reason that the previous proposal faile=
d
>> was that it introduced too much ambiguity about how to resolve
>> unknown-type arguments.  Wouldn't the same problems arise here?

> By adding a different function, there is no prior behavior to worry abou=
t.

True, that's one less thing to worry about.

> So we should be safe with the following signatures doing the right thing=
,
> yes?:
>     generate_finite_series(start timestamp, step interval, num_elements
> integer)
>     generate_finite_series(start date, step integer, num_elements intege=
r)
>     generate_finite_series(start date, step interval year to month,
> num_elements integer)

No.  You can experiment with it easily enough using stub functions:

regression=3D# create function generate_finite_series(start timestamp, ste=
p interval, num_elements
regression(# integer) returns timestamp as 'select $1' language sql;
CREATE FUNCTION
regression=3D# create function generate_finite_series(start date, step int=
eger, num_elements integer) returns timestamp as 'select $1' language sql;
CREATE FUNCTION
regression=3D# create function generate_finite_series(start date, step int=
erval year to month,
regression(# num_elements integer) returns timestamp as 'select $1' langua=
ge sql;;
CREATE FUNCTION

regression=3D# select generate_finite_series(current_date, '1 day', 10);
ERROR:  function generate_finite_series(date, unknown, integer) is not uni=
que
LINE 1: select generate_finite_series(current_date, '1 day', 10);
               ^
HINT:  Could not choose a best candidate function. You might need to add e=
xplicit type casts.

It's even worse if the first argument is also an unknown-type literal.
Sure, you could add explicit casts to force the choice of variant,
but then ease of use went out the window somewhere --- and IMO this
proposal is mostly about ease of use, since there's no fundamentally
new functionality.

It looks like you could make it work with just these three variants:

regression=3D# \df generate_finite_series
                                                               List of fun=
ctions
 Schema |          Name          |      Result data type       |          =
                Argument data types                           | Type =

--------+------------------------+-----------------------------+----------=
--------------------------------------------------------------+------
 public | generate_finite_series | timestamp without time zone | start dat=
e, step interval, num_elements integer                        | func
 public | generate_finite_series | timestamp with time zone    | start tim=
estamp with time zone, step interval, num_elements integer    | func
 public | generate_finite_series | timestamp without time zone | start tim=
estamp without time zone, step interval, num_elements integer | func
(3 rows)

I get non-error results with these:

regression=3D# select generate_finite_series(current_date, '1 day', 10);
 generate_finite_series =

------------------------
 2022-05-10 00:00:00
(1 row)

regression=3D# select generate_finite_series('now', '1 day', 10);
    generate_finite_series     =

-------------------------------
 2022-05-10 19:35:33.773738-04
(1 row)

That shows that an unknown-type literal in the first argument will default
to timestamptz given these choices, which seems like a sane default.

BTW, you don't get to say "interval year to month" as a function argument,
or at least it won't do anything useful.  If you want to restrict the
contents of the interval it'll have to be a runtime check inside the
function.

			regards, tom lane