From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Richard Wesley <richard(at)duckdblabs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Query generates infinite loop |
Date: | 2022-05-09 16:42:44 |
Message-ID: | 3817754.1652114564@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> The infinite-upper-bound-withlimit-pushdown counterexample makes sense, but
> seems like we're using generate_series() only because we lack a function
> that generates a series of N elements, without a specified upper bound,
> something like
> generate_finite_series( start, step, num_elements )
Yeah, that could be a reasonable thing to add.
> And if we did that, I'd lobby that we have one that takes dates as well as
> one that takes timestamps, because that was my reason for starting the
> thread above.
Less sure about that. ISTM the reason that the previous proposal failed
was that it introduced too much ambiguity about how to resolve
unknown-type arguments. Wouldn't the same problems arise here?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2022-05-09 17:20:23 | Re: BUG #17477: A crash bug in transformValuesClause() |
Previous Message | Tom Lane | 2022-05-09 16:32:23 | Re: BUG #17478: Missing documents in the index after CREATE INDEX CONCURRENTLY (but existing in the table) |
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2022-05-09 18:44:45 | Re: Privileges on PUBLICATION |
Previous Message | Justin Pryzby | 2022-05-09 15:58:15 | Re: postgres_fdw "parallel_commit" docs |