Revised patch: Differences in this patch vs my first one: - infinite bounds generate errors identical to Michael's timestamp patch (though I did like Simon's highly optimistic error message). - Bounds checking moved before memory context allocation - arg variable "finish" renamed "stop" to match parameter name in documentation and error message
On Tue, Jan 26, 2016 at 12:47 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > On Tue, Jan 26, 2016 at 7:53 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Tue, Jan 26, 2016 at 7:00 PM, Torsten Zuehlsdorff >> <mailingli...@toco-domains.de> wrote: >> > >> > On 26.01.2016 07:52, Simon Riggs wrote: >> > >> >>> Imagine for example a script that in some rare cases passes happens to >> >>> pass infinity into generate_series() - in that case I'd much rather >> error >> >>> out than wait till the end of the universe. >> >>> >> >>> So +1 from me to checking for infinity. >> >>> >> >> >> >> +1 >> >> >> >> ERROR infinite result sets are not supported, yet >> > >> > >> > Maybe we should skip the "yet". Or do we really plan to support them in >> > (infinite) future? ;) >> > >> > +1 from me to check infinity also. >> >> Something like the patch attached would be fine? This wins a backpatch >> because the query continuously running eats memory, no? >> -- >> Michael >> >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers >> >> > I'll modify my generate_series_date to give similar errors. > > I have no opinion on backpatch. > > +1 for flippant references to infinity. > >
v2.generate_series_date.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
